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ABSTRACT 


In  1974,  the  Naval  Supply  Systems  Command  initiated 
actions  to  automate  the  procurement  process  within  the  Navy 
Pie  Id  Contracting  System  (NPCS) .  The  development  project 
was  titled.  Automation  of  Procurement  and  Accounting  Data 
Entry  (APADE)  .  By  1979,  the  original  project  was  discon¬ 
tinued  and  a  redesign  effort  was  initiated.  In  an  effort  to 
determine  the  underlying  reasons  for  the  project* s  delay  and 
problems  encountered  in  developing  an  Automated  Data  System 
(ADS)  ,  this  thesis  examines  the  APADE  project.  In  addition 
to  the  reasons  and  probLems  addressed  by  the  Naval  Data 
Automation  Command's  evaluation  report,  the  researcher 
concluded  that  the  procurement  procedures  utilized  by  the 
NPCS  activities  were  not  defined  a  or  standardized  suffi¬ 
ciently  to  facilitate  ADS  development.  Additionally,  there 
was  no  indication  that  this  situation  was  addressed  or 
corrected  during  th  planning  phase  of  APADE  II  development. 
The  researcher  also  concluded  that  various  environmental 
conditions  significantly  impacted  upon  the  development 
process. 
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I.  I  NTRODSQIIi’I 


A.  NAVAL  FIELD  CONTE  ACTTN 3  SYSTEM  MISSION 

The  Naval  Supply  Systems  Command's  (NAVStIP)  charter 
specifically  assigns  them  with  the  responsibility  for  the 
procurement  of  material  and  services  throughout  the 
Department  of  the  Navy  except  as  otherwise  delegated  by 
higher  authority.  Included  within  this  procurement 

authority  is  the  management  responsibility  for  the  Navy 
Field  Contracting  System  (NFCS)  .  The  NFCS  consist  of  field 
activities,  located  at  various  Naval  facilities,  with  dele¬ 
gated  procurement  authority  of  various  monetary  thresholds. 
It  is  with  the  field  activities  that  the  ultimate  responsi¬ 
bility  of  satisfying  all  the  fleet  purchase  request  depends. 

It  is  the  inherent  overall  mission  of  the  NFCS  to 
provide  effective  and  efficient  procurement  services  to 
fleet  units  and  Naval  Shore  activities.  This  service 
includes  supplying  locally-procured  standard  items,  non¬ 
standard  material,  and  other  services.  Effective  perfor¬ 
mance  cf  the  procurement  function  consists  of  providing  the 
customer  the  material  or  service  requested  at  the  time  it  is 
needed  and  at  the  best  possible  price. 

B.  BACKGROUND 

Over  the  last  decade,  a  major  criticism  of  the  Navy 
Field  Contracting  System  has  been  inadequate  procurement 
response  time  (the  time  elapsing  from  submission  of  the 
end-use  requisition  to  delivery  of  the  needed  material  or 
service).  During  the  early  1970s,  the  Naval  Supply  Systems 
Command  (NAVSUP)  became  aware  of  several  common  problems 


which  surfaced  during  studies  conducted  on  the  procurement 
process.  They  were: 

1.  Lack  of  standardization, 

2.  Untimely  status  Information, 

3.  Inflexible  management  reports,  and 

4.  Interface  only  with  hard  copy  documents. 

All  of  these  problems  impacted  upon  the  total  responsiveness 
of  the  procurement  process  and  directly  affected  the  mission 
capability  of  the  NFCS. 

In  1974,  as  a  direct  result  of  these  studies,  NAYSU? 
initiated  actions  to  automate  the  procurement  process  at  the 
major  NFCS  activities.  These  are  comprised  of  the  Naval 
Supply  Centers  (NSC)  and  Naval  Regional  Contracting  Centers 
(NRCC).  NAY SOP  envisioned  a  system  that  would  overcome  the 
deficiencies  and  enhance  the  response  time  of  the  procure¬ 
ment  process. 

The  automated  system's  major  objectives  would  be  to: 

1.  Automate  the  procurement  document  preparation, 

2.  Management  tracking, 

3.  Control  of  non-standard  requisition  documents, 

4.  status  reports  to  customers, 

5.  Generate  management  statistics  and  reports,  and 

6.  Automate  the  interface  with  the  accounting  functions. 

In  April  of  1975,  a  research  and  development  project,  APADF 
I  (Automation  of  Procurement  and  Accounting  Data  Entry) ,  was 
initiated.  Although  the  35 D  effort  set  with  limited  sucess, 
it  demonstrated  a  definite  need  to  automate  the  procurement 
process.  By  1977,  NAVSOP  directed  that  system  development, 
APADE  II,  be  initiated  with  a  total  system  package  scheduled 
for  completion  on  April  of  1979. 


In  November  1979,  with  only  partial  development  and 
implementation  at  two  prototype  sites  completed,  the  Chief 
of  Naval  Operations  recommended  to  N  AVSUP  that  further 
development  and  implementation  be  discontinued  until  the 
Automated  Data  System  (ADS)  plan  was  rewritten  and  hardware 
requirements  analyzed.  The  new  development  effort  was  to  be 
accomplished  in  accordance  with  the  current  directives  on 
the  Navy's  Automated  Data  System  Program. 

C.  OBJECTIVE 

It  is  intended  that  the  presentation  of  this  Thesis  will 
serve  three  major  objectives. 

First,  through  the  presentation  of  a  documented  record 
of  the  major  efforts  to  automats  the  procurement  process 
within  the  NFCS,  the  underlying  reasons  for  the  project's 
delay  and  the  problems  cited  by  the  Naval  Data  Aatomation 
Ccmmand's  project  evaluation  report  will  surface. 

Secondly,  and  perhaps  more  importantly,  by  describing 
the  various  phases  of  development  of  the  APADE  project  and 
comparing  them  to  a  recommended  ADS  development  process, 
valuable  insight  of  the  problems  involved  in  designing, 
developing,  and  implementing  an  automated  system  will 
promote  improved  managerial  decisions  concerning  automation. 

The  final  objective  is  to  contribute  an  c^srall  benefit 
by  presenting  a  documented  historical  record  of  the  events 
to  facilitate  the  current  automation  effort  of  the  procure¬ 
ment  process. 

D.  SCOPE 

The  effort  to  automane  the  NFCS  procurement  process  has 
covered  a  minimum  of  eight  years.  Over  that  time  period, 
there  have  been  seven  commands  within  the  Department  of  tha 
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Navy,  four  private  contractors  and  the  General  Service 
Adainistration  (GS A)  associated  with  the  project  in  one  fora 
or  another.  It  is  impossible  to  record,  within  a  reasonable 
amount  of  time,  all  of  the  correspondence  and  documentation 
which  transpired  during  that  period.  Accordingly,  this 
study  examines  the  key  documentation  and  correspondence 
submitted  and  received  by  the  Fleet  Material  Support  Office 
(FMSO) ,  in  the  role  as  central  Design  Agency  for  the 
project;  the  GSA  involvement;  the  role  of  NAVSDP  as  the 
project  manager;  and,  finally,  the  utilization  of  a  private 
contractor  to  design,  develop,  and  implement  the  system. 

Additionally,  to  provide  a  sound  basis  from  which  to 
examine  the  automation  effort,  this  paper  will  initially 
focus  on  twc  specific  areas.  The  first  area  to  be  examined 
will  be  the  role  of  the  MFCS  and  the  procurement  process  at 
the  major  activities.  The  second  area  will  be  the  evolution 
of  the  Navy's  Automated  Data  System  program  and  applicable 
regulations  in  effect  during  the  automation  effort. 

E.  METHODOLOGY 

The  research  of  the  subject  was  first  initiated  after  a 
telephone  conversation  with  the  Fxecutive  Officer,  Fleet 
Material  Support  Office  (FMSO)  Nechanoisburg,  Pennsylvania  on 
23  February  1982  indicated  that  the  researcher's  next  duty 
assignment  would  be  at  FMSO  as  the  APADE  project  officer. 
The  Executive  Officer  stated  that  a  historical  research  of 
the  APADE  effort  could  provide  valuable  lessons  for  future 
managers  of  the  Navy's  resources  in  addition  to  providing 
the  researcher  with  the  required  insight  to  assume  the  new 
duties. 

Data  was  collected  on  three  levels;  (a)  field  research 
at  Naval  Supply  Center  Oakland,  FMSO,  and  Naval  Supply 
Systems  Command,  Washington  D.C.;  ( b >  Discussions  and  phone 


conversations  with  various  agency  pe.sonnel;  (c)  research  as 
indicated  in  the  list  of  references. 

F.  THESIS  ORGANIZATION 

The  format  described  in  the  table  of  contents  was  chosen 
because  it  seems  to  present  the  material  in  a  logical 
sequence.  Chapter  One  is  the  introduction  and  consists  of  a 
brief  discussion  of  the  automation  effort  with  the  scope  and 
objective  of  the  research  effort.  The  methodology  of 
collecting  the  data  is  also  provided.  The  next  chapter  is 
devoted  to  the  discussion  of  the  role  of  the  NFCS  within  rhe 
NAVS3P  organization.  A  detailed  explanation  of  the  procure¬ 
ment  process  and  the  problems  encountered  are  also 
presented.  Chapter  Three  provides  the  reader  with  insight 
of  the  Navy's  ADP  Program,  its  objectives  and  the  laws  and 
regulations  that  control  it.  The  fourth  chapter  is  a 
detailed  analysis  of  the  automation  effort  as  examined  from 
various  correspondence,  files,  publications  and  interviews. 
Chapter  Five  discusses  the  NAVDAC  evaluation  and  constraints 
placed  on  the  project  by  the  CNO.  Chapter  Six  contains  the 
researcher's  conclusions. 
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II .  NAVI  lllh 2  CONTRACTING  SYSTEM 


is  mentioned  in  the  introduction,  to  facilitate  the 
examination  of  the  effect  to  automate  the  procurement 
process  within  the  Navy  Pield  Contracting  System (NFCS) ,  it 
is  essential  to  first  focus  on  the  organizational 
characteristics  and  functional  requirements  of  the  system. 

A.  BACKGH  OUND 

The  Navy  Pield  Contracting  System,  under  the  cognizance 
of  the  Naval  Supply  Systems  Command  (NAVSDP),  consists  of 
all  contracting  offices  of  Naval  activities  except  the 
following: 

1.  Automatic  Data  Processing  Selection  Office, 

2.  Office  of  Naval  Research  its  Branch  offices  and  its 
Resident  Representatives, 

3.  Military  Sealift  Command  and  its  field  activities, 

h.  Marine  Corps  and  its  field  activities;  however,  its 
air  stations  are  a  part  of  the  NFCS, 

5.  Headquarters,  Naval  Air  Systems  Command,  its  Naval 
Plant  Representatives  Offices  and  its  Naval  Aviation 
Logistic  Center,  Commercial  Rework  Department, 

6.  Headquarters,  Naval  Sea  System  Command,  its  Naval 
Plant  Representative  Offices  and  its  Supervisor  of 
Shipbuilding,  Conversion  and  Repair, 

7.  Headquarters,  Naval  Electronic  System  Comm  and,  and 

3.  Headquarters,  Naval  Facilities  Engineering  Command  and 
its  field  activities  [Ref.  1:  p.  1-401. 51b]. 

In  fcotal,  the  NFCS  is  comprised  of  several  hundred  indivi¬ 
dual  activities,  each  having  a  limit  to  their  purchasing 


authority  as  perscribed  by  the  Naval  Supply  Systems 
Command  (NAVSUP)  . 

Centralized  control  is  provided  by  the  establishment  of 
nine  geographical  procurement  regions  throughout  the  world. 
Six  of  the  regions  are  located  within  the  Continental  U.S. 
with  the  remaining  three  being  Hawaii,  Par  East,  and  Europe. 
Each  region  has  a  Naval  Supply  Center  (NSC),  Naval  Supply 
Depot  (NS D)  ,  or  Naval  Regional  Contracting  Center  (NRCC) , 
formerly  known  as  Naval  Regional  Contracting  Office  (NRCO) , 
designated  as  the  cognizant  contracting  office  for  that 
region.  It  is  within  this  organizational  framework  that 
NAP  SOP  centralizes  the  buying  by  region,  area,  or  commodity 
to  the  maximum  extent  possible. 

B.  CATEGORIES  OP  PURCHASING  ACTIVITIES 

NAVSUP  categorizes  purchasing  activities  by  defining 
them  by  the  type  of  authority  and  responsibility  they  have 
with  respect  to  purchasing.  The  three  categories  are:  (1) 
central  buying,  (2)  noncentral  buying,  and  (3)  limited 
buy  in  g. 

1  -  Central  Buying 

There  are  three  different  levels  of  centralized 
buying.  The  first  level  is  regional  buying.  The  acrivites 
designated  for  regional  buying  are  the  NSC’s  and  NRCC’s. 
They  are  responsible  for  buying  items  assigned  by  NAVSUP  and 
for  making  purchases  which  exceed  the  limited  purchase 
authority  of  the  activities  within  their  jurisidiction.  In 
addition,  for  activities  designated  as  the  regional 
contracting  office  for  their  region,  the  responsibility  of 
assisting  NAVSUP  in  meeting  the  functional  and  nonfunctional 
management  requirements  is  assigned.  This  includes,  but  is 
not  limited  to: 
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1.  Providing  guidance  and  technical  assistance, 

2.  Evaluating  staffing,  performance,  and  effectiveness  of 
MFCS  contracting  offices, 

3.  Determining  compliance  with  applicable  priorities  of 
lav  and  regulations,  and 

4.  Assigning  contracting  officer  authority  for  NFCS 
activities  and  personnel. 

The  second  level  of  centralized  buying  is  area 
buying.  These  are  Navy  field  activities,  designated  by 
NAV SOP ,  responsible  for  purchases  which  are  in  excess  of  the 
contracting  authority  granted  to  other  Naval  activities 
located  within  a  particluar  area.  Currently,  there  are 
seven  area  buying  activities  located  within  the  Continential 
U.S.  They  are: 

1.  Naval  Air  Station,  Jacksonville,  Fla., 

2.  Naval  Air  Station,  Pensacola,  Fla., 

3.  Naval  Air  Station,  Corpus  Christi,  Tx., 

4.  Naval  Shipyard,  Portsmouth,  N.H., 

5.  Naval  Supply  Center,  Puget  sound,  wa., 

6.  Naval  Supply  Center,  San  Diego,  Ca.,  and 

7.  Supply  Department,  Naval  Administrative  Command,  Naval 
Training  Center,  Sreat  Lakes,  Ill. 

Additionally,  the  area  buying  activities  will  make  purchases 
which  are  withir.  the  authority  of  the  activities  they 
service  when  it  is  advantageous  due  to  complexity  of  the 
purchase  or  their  additional  capabilities  are  required. 

The  third  level  of  centralized  buying  is  commodity. 
This  level  of  buying  is  only  performed  by  *he  NAVSUP  managed 
inventory  control  points  (I  CP  ’  s)  .  Purchasing  by  ICP's  is 
usually  for  new  stock  requirements  and  system  stock  replen¬ 
ishment  for  support  cf  major  systems  throught  the  Navy.  The 
activities  designated  as  inventory  oontol  points  are: 
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1.  Navy  Aviation  Supply  Office, 

2.  Navy  Ships  Parts  Control  Center,  and 

3.  Navy  Resale  and  Service  Support  Center. 

2.  Nonceptral  Bu yin a 

In  general,  activities  designated  as  noncentral 
buying  activities  are  responsible  for  buying  supplies  and 
services  in  support  of  their  assigned  mission  as  well  as  for 
local  use.  Purchases  are  lade  within  the  monetary  limits  as 
imposed  by  NAVSUP.  Examples  of  noncentral  buying  activities 
are:  Naval  Shipyards,  Naval  Air  Development  Centers,  Naval 
Weapons  Canters,  and  Naval  Construction  3attalicns.  The 
imposed  purchase  limitation  is  usually  $100,300  with  the 
exception  of  Naval  Shipyards  engaged  in  the  Naval  Nuclear 
Propulsion  Program.  They  have  unlimited  purchase  authority 
within  their  mission  area. 

3 •  Limited  Buying 

Limited  buying  activities  are  those  designated  in 
writing  by  NAVSUP  assigning  purchase  authority  and  types  of 
purchases  allowed.  Examples  of  these  activities  are 
Commissary  Stores,  Naval  Reserve  Office  Training  Corps,  and 
Naval  Health  Sciences  Education  and  Training  Command. 

C.  PROCUREMENT  PROCESS 

For  the  purpose  of  analyzing  the  procurement  process 
within  *he  NFCS,  attention  will  be  focused  on  the  regional 
buying  activities  (NSC  and  NRCC) .  The  reason  for  analyzing 
the  procurement  process  at  the  NSC  and  NRCC  is  two-fold. 
First,  the  majority  of  the  automation  effort  has  concen¬ 
trated  on  analyzing  the  procurement  process  at  the  regional 
buying  activities  due  zo  the  large  volume  in  procurement 
actions.  Secondly,  it  provides  a  better  understanding  of 
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the  magnitude  and  scope  of  the  overall  procurement  process 
in  the  NFCS  by  examining  the  organization  and  functions  of 
these  two  activities. 

1.  N§£  ami  H£££  Organization 

although  the  NSC’s  and  NRCC’s  are  responsible  for 
performing  the  same  procurement  mission  and  governed  by  the 
same  purchase  regulations,  there  is  a  significant  difference 
in  their  organizational  composition  to  accomplish  that 
mission.  The  NSC  procurement  component  functions  as  a 
department  within  that  activity  as  contrasted  to  the  autono¬ 
mous  NRCC.  These  relationships  are  exhibited  by  Figures  2.1 
and  2.2. 

a.  NSC  Purchase  Department 

The  purchase  department  in  the  standard  NSC  is 
comprised  of  three  separate  divisions  which  share  the 
overall  responsibility  to  plan  and  conduct  purchase  and 
contract  administration  operations  for  the  activity.  The 
following  is  a  brief  discussion  of  those  divisions'  respon¬ 
sibilities  within  the  organization. 

Buying  and  Order  Division 

The  Buying  and  Order  Division  is  responsible 

for : 

1.  Reviewing  purchase  request, 

2.  Determining  types  and  methods  of  purchase, 

3.  Reviewing  qualifications  of  contractors, 

4.  Performing  bid  analysis, 

5.  Performing  negotiations  with  contractors,  and 

6.  Flacing  orders  under  established  federal  contracts. 
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Figure  2.1  Standard  Organ izattions  for  BSC  and  Depots 
(HA7S0P  Ban.  7 ol.i) 


Purchase  Service  Division 

The  Purchase  Service  Division  is  responsible  for 
preparing  and  issuing  all  invitations  for  bids  and  request 
for  proposals  as  directed  by  the  buying  and  order  division. 
In  addition,  they  maintain  records  of  bids  received,  assign 
purchase  request  to  cognizant  buyers,  prepare  and  issue  all 
contractual  documents,  maintain  control  records,  and  prepare 
statistical  procurement  reports. 
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Assistan 


Officer  in  Charge  | 

t  Officer  in  Charge 


1.  Amend,  modify,  and  terminate  contracts  due  to  default; 

2.  Collect,  assemble,  analyze,  and  promulgate  contractor 
performance  data;  and 

3.  In  cases  of  delinquent  deliveries,  effect  contractor 
discipline. 

b.  NRCC  Purchase  Drganization 

As  previously  mentioned,  the  SRCC’s  carry  out 
their  assigned  mission  as  a  completely  autonomous  organiza¬ 
tion.  However,  like  the  NSC's,  they  have  three  divisions 

tha*  share  in  the  responsibilities  of  that  mission. 

Field  Management  Division 

This  division  provides  the  purchase  management 
guidance,  assistance,  and  advise  to  the  NFCS  activities 

within  their  cognizant  regional  areas  as  delegated  by 
NAV SUP.  The  general  duties  of  the  division  are  comprised  of 
♦he  following; 

1.  Appraise  organization  and  staffing, 

2.  Evaluate  levels  of  contracting  authority, 

3.  Administer  and  coordinate  purchasing  training 

programs, 

n.  Prescribe  standard  operating  procedures, 

5.  Advance  planning, 

6.  Analyze  purchase  statistics,  trends,  workloads  for 
management  effectiveness,  and 

7.  Determine  the  need  for  indefinite  delivery  type 
contracts  for  common  type  items. 

Administrative  and  Planning  Division 

The  administrative  and  planning  division 
performs  administrative,  planning,  personnel,  office 

service,  and  purchase  support  services  such  as; 
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1.  Analyzing  internal  operating  methods, 

|  2.  Administering  various  management  improvement  programs, 

3.  Estimating  budget  and  personnel  ceiling  requirements, 

4.  Preparing  and  maintaining  administrative  directives, 

5.  Providing  mail,  filing,  and  duplicating  services, 

|  6.  Screening,  recording,  and  routing  all  incoming 

purchase  request, 

7.  Preparing  and  mailing  invitation  for  bids  (IPB)  and 
request  for  proposals  (SPP) , 

|  8.  Maintaining  contract  files, and 

9.  Preparing  external  statistics  and  procurement  reports 
for  the  activity. 

Purchase  Division 

I  The  purchase  division  of  the  NRCC  plans  and 

conducts  the  purchase  and  contract  administration  functions 
for  the  activity.  That  responsibility  includes  the 


following: 

1.  Reviews  purchase  request  for  correctness, 

2.  Analyzes  and  evaluate  bids  and  proposals, 

3.  Directs  the  issuance  of  IPBS  and  RFPs, 

4.  Conducts  contract  negotiations, 

5.  Participates  in  pre-award  surveys, 

6.  Determines  contractor  responsibility,  capacity,  and 
performance  status, 

7.  Determines  when  to  award,  amendment,  claim,  and  termi¬ 
nate  contracts,  and 

9.  Performs  contract  administration  functions. 


2.  N§£  H2££  £l2SSJ£iaiHi 

Basically,  the  overall  procurement  missions  of  the 
MSC * s  and  WRCC’s  are  identical.  They  are  both  responsible 
for  satisfying  the  purchase  requirements  of  the  fleet  as 


well  as  all  purchase  requirements  exceeding  the  limited 
purchase  authority  of  other  Navy  shore  activities  within 
their  cognizant  geographical  region.  They  have  both  been 
granted  unlimited  purchase  authority  by  NAVSOP.  The  infor¬ 
mation  requirements,  regulations,  functions,  and  procedures 
of  the  NSCs  and  NRCCs  to  carry  out  these  responsibilities 
are  governed  by  the  Defease  Acquisition  Regulations  (DAR) , 
Navy  Contracting  Directives,  the  NAVSUP  Fieli  Purchasincr 
Manual  (NAVSUP  P-467)  ,  N  AVS  UP  policy  guidance,  and  locally- 
developed  instructions. 

Although  the  NSC's  and  NRCC' s  are  organizationally 
different,  the  basic  procurement  functions  of  these  activi¬ 
ties  are  sufficiently  similar  to  be  described  by  one  gener¬ 
alized  information  flow.  This  is  graphically  displayed  by 
Figure  2.3. 

Processing  starts  with  the  receipt  of  a  purchase 
request  at  the  procurement  office.  Requisitions  are  usually 
received  in  the  form  of  a  hard-copy  document  or  punched 
card.  Specifications,  drawings,  and  other  supporting  docu¬ 
mentation  will  be  provided  as  required.  A  control  desk  is 
usually  established  to  manually  log-in  each  document  by 
requisition  number,  date  received,  dollar  value,  and 
description.  The  requisitions  are  then  sorted  according  to 
a  customer  assigned  priority  number.  They  are  screened  for 
completeness,  consolidated  when  appropriate,  assigned  a 
Control  Number,  and  placed  in  folders.  The  control  desk 
determines  the  commodity  and  assigns  the  appropriate  buyer 
or  organizational  code  depending  on  local  criteria.  The 
buyer  receives  the  requisition  and  reviews  it  for  complet- 
ness  and  accuracy. 

At  this  point,  the  next  procedure  depends  or.  the 
estimated  value  of  the  procurement  action.  For  small 
purchases,  under  510,  000  (Changed  to  525,000  in  April  1982), 


Figure  2.3  Procurement  Process  (Sef.  2) 
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the  buyer  will  issue  a  Request  For  Quote  (SFQ)  or  obtain  ar. 
oral  quotation  since  the  regulations  allow  him/her  to 
perform  the  procurement  by  negotiation  vice  formal  adver¬ 
tisement.  However,  for  procurements  exceeding  the  $10,000 
($25,000)  threshold,  the  buyer  must  either  issue  a  formal 
Invitation  For  Bid  ( IFB)  or  obtain  approval  from  a  higher 
level  to  negotiate  the  procurement.  After  determining  the 
method  of  procurement,  IFB  or  negotiation,  the  process  is 
basically  the  same. 

After  the  buyer  receives  the  offers  from  prospective 
contractors,  those  offers  are  evaluated  and  contracts  are 
awarded  or  order  placed  with  the  successful  vendor.  The 
contract  documents  are  signed,  distributed,  and  filed  for 
use  by  personnel  administrating  the  contract  until  all 
action  is  completed  and  the  vendors  invoice  is  paid. 
Additionally,  regulations  require  that  these  files  be  kept 
for  a  period  of  seven  years . 

It  should  be  understood  at  this  point  that  this 
discription  has  been  highly  simplified  to  enhance  the  read¬ 
er's  understanding.  The  regulatory  requirements  and  the 
procedural  details  dealing  with  contract  preparation,  evalu¬ 
ation,  negotiation,  and  solicitation  in  conjunction  with 
contract  administration  can  only  be  fully  appreciated  by  an 
indepth  study  of  the  laws  and  regulations  of  government 
procurement.  Since  this  examination  is  concerned  with  the 
automation  of  the  procurement  process,  an  indepth  study  of 
this  magnitude  is  considered  beyond  the  scope  of  the 
research.  However,  a  list  of  the  required  input,  output, 
and  report  documentation  should  provide  the  reader  with  an 
appreciation  of  the  scope  of  the  procurement  process. 
Appendix  A  provides  a  list  of  the  major  input,  output  and, 
report  documents  required  by  these  two  Navy  activities. 
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D.  PROBLEM  AREAS 


In  the  early  1970s,  several  stadias  of  the  government 
procurement  process  were  initiated.  This  mainly  stemmed 
from  the  1972  Report  to  Congress  from  the  Commission  on 
Government  Procurement.  Because  of  the  increased  emphasis 
placed  on  government  procurement,  the  Navy  began  to  perform 
evaluations  at  its  procurement  activities  in  order  to 
surface  and  correct  potential  problem  areas. 

One  of  the  first  problems  identified  at  the  NSC's  and 
NRCC's  was  inefficiency  due  to  highly  labor-intensive 
procurement  actions  with  relatively  little  data  processing 
support.  All  document  preparation  and  file  maintenance  was 
done  manually.  The  data  processing  support  received  by  the 
NSC  purchase  function  was  provided  by  a  different  oraaniza- 
tional  component  of  the  Supply  Center.  This  required  the 
sharing  of  large-scale  equipment  which  supported  a  wide 
range  of  functions.  Although  the  NRCC's  had  more  control  of 
their  data  processing  resources,  they  were  limited  in  size 
and  capacity  [Ref.  2:  p.4.1-2]. 

A  second  problem  identified  was  the  lack  of  standardized 
procedures.  Although  both  activities  are  governed  by  the 
same  laws  and  regulations,  the  manner  in  which  they  inter¬ 
preted  the  regulations  and  methods  employed  in  enforcing  the 
regulations  varied  considerably.  A  major  reason  for  this 
was  the  different  types  of  supplies  and  services  procured  by 
each  activity.  Another  problem  identified  was  the  untimely 
flow  of  information  on  the  status  of  the  procurement 
actions.  Customer  queries  for  status  are  handled  by  the 
buyers  who  must  divert  their  time  from  the  buying  action  to 
perform  mundane  document  searches.  This  resulted  in 
searches  being  performed  whenever  the  buyer  could  "get  to 
it"  [Ref.  2:  p.4.1-3]. 
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The  inability  of  the  current  procurement  system  to 
interface  effectively  with  the  other  D3D  and  Navy  financial, 
supply,  and  contract  administration  systems  surfaced  as 
another  major  weakness.  The  majority  of  interfacing  was 
through  copies  of  contract  documents  and  other  non-machine- 
processable  media.  This  usually  resulted  in  additional 
errors  and  sometimes  the  non-reconciliation  of  financial 
accounts  and  untimely  information. 

Other  problems  identified  were  dalays  ir.  the  preparation 
of  formal  procurement  documents  and  lanual  entry  of  procure¬ 
ment  data  with  a  high  incidence  of  duplication. 

As  these  problem  areas  were  identified,  NAVStJp  began  to 
understand  why  the  effectiveness  of  the  NFC5  was  dimin¬ 
ishing.  Collectively,  the  problems  created  excessive 
response  time  in  the  processing  of  procurement  actions. 
This  lead  to  a  reduction  in  mission  performance  and  customer 
dissatisfaction.  NAVSUP,  in  1974,  initiated  action  to  auto¬ 
mate  the  procurement  process  in  an  attempt  to  find  a  solu¬ 
tion  to  their  problems.  However,  they  first  had  to  rely  on 
the  Navy's  ADP  Program. 


III.  NA2IIS  4SI2MAI SD  Uklh  processing  program 


A.  BACKGROUND 

As  John  Mauchly  and  J. P.  Eckert  constructed  the  first 
all -electronic  computer,  ENIAC,  in  1945,  little  could  they 
have  realized  the  total  proliferation  of  computers  within 
the  federal  government  thirty  years  hence.  The  first  compu¬ 
ters  installed  in  the  government  were  mainly  used  to  support 
research  projects  within  DDD.  The  first  general  purpose  or 
business  use  of  a  computer  was  by  the  Bureau  of  Census  to 
compile  the  1950  census  data.  By  1965,  the  number  of 
general  purpose  computers  utilized  by  the  federal  government 
increased  to  2,412  with  a  data  processing  price  tag  over 
$1,132  billion.  This  significant  increase  in  volume  was 
mainly  attributable  to  the  employment  of  general  purpose 
computers  in  the  fields  of  material,  financial,  and  adminis¬ 
trative  management.  By  1977,  there  were  over  11,000  general 
purpose  computer  systems  in  operation  within  the  government 
[ Re f.  3s  p.  1  ]. 

1 .  U.  S .  Navy 

A  major  user  of  computer  technology  within  DOD  is 
the  Department  of  the  Navy  (DON) .  From  1959  to  1975,  DON 
had  spent  more  than  2.3  billion  dollars  for  Automatic  Data 
Processing  Equipment  (ADPE)  and  had  acquired  over  1100 
general  purpose  computer  systems  to  perform  logistic  and 
administrative  functions.  As  of  April  1982,  DON  had  a  total 
of  2728  systems  and  approximately  14,634  personnel  associ¬ 
ated  with  the  operation  and  maintenance  of  those  systems. 
The  DON  1933  fiscal  year  budget  included  1.035  billion 
dollars  for  the  acquisition  and  maintenance  of  ADP  systems 
[Ref.  4]. 
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Forecasting  tha  future  demand  on  computer  systems, 
the  DON  established,  in  1959,  an  Automatic  Data  Processing 
Program  to  control  the  valuable  data  processing  resources. 
The  program  was  and  is  today  a  compilation  of  Navy  policies, 
objectives,  plans,  procedures,  and  principles  for  managing 
ADP  resources.  The  program  is  further  intended  to  enhance 
tha  Navy  capabilities  in  the  computer  field.  It  provides 
general  guidance  to  Navy  components  for  technical  advance¬ 
ment  and  effective,  efficient,  and  economical  use  of 
computer  equipment  and  techniques  [Ref.  5:  p.  1  ]. 

The  program’s  general  guidance  presents  principles 
for  long  range  development  of  the  Navy’s  data  processing 
capabilities  as  well  as  exploitation  of  computer  technology, 
telecommunications,  and  management  science  techniques.  The 
program  is  headed  by  the  Deputy  Under  Secretary  of  the  Navy 
(Financial  Management)  who  is  designated  the  Senior  Policy 
Official  (SPO)  for  ADP.  The  Chief  of  Naval  Operations 
(OP-942)  is  "dual- haf  ted'*  as  the  Director,  Department  of  the 
Navy  ADP  Management  (DIR  DON  ADPM)  . 

2.  Objectives  and  Prin ci pies  of  the  Program 

THe  Navy’s  ADP  program  objectives  were  officially 
established  through  the  promulgation  of  a  general  plan  by 
the  Secretary  of  the  Navy  (SECNAV)  in  1959.  The  major  objec¬ 
tives  outlined  by  that  plan  were: 

1.  The  combining  of  the  automated  management  information 
systems  to  form  an  aggregated  system  termed,  "a 
Department  of  the  Navy  management  information  system,” 

2.  The  systematic  evolution  and  application  of  automatic 
data  processing  equipment  and  associated  techniques  in 
improving  information  flow  to  and  from  management  with 
optimal  uniformity,  c ompa tabili t y ,  and  responsiveness. 


3.  The  development  and  exploitation  of  automatic  data 
processing  equipment  and  related  advanced  scientific 
techniques#  and 

4.  The  orderly  development  of  standardization  to  improve 
information  interchange  [Ref.  5:  p.2]. 

Included  in  the  general  plan  were  the  policies# 
principles,  concepts,  and  procedures  to  be  followed  to 
ensure  proper  implementation  of  program  objectives  by  the 
various  Navy  organizations.  It  provided  major  stages  of 
system  development  and  detailed  instructions  for  conducting 
planning  and  feasibility  studies.  Purther  guidance  was 
provided  concerning  the  policy  of  system  design#  acquisi¬ 
tion#  installation#  and  conversion  of  ADP  systems.  In  addi¬ 
tion#  *he  plan  outlined  general  principles  dealing  with  the 
need  for: 

1.  Preparing  economic  analysis  to  determine  benefits  of 
automation  and  its  impact  on  direct  and  indirect  cost, 

2.  Exploiting  the  full  capabilities  of  available  equip¬ 
ment  and  the  management  sciences# 

3.  Automating  applications  which  have  a  legitimate 
history  and  purpose  with  consistency  and  prudent 
speed,  and 

4.  Continuously  anticipating  and  implementing  reorganiza¬ 
tion  [Ref.  5:  p.2]. 

By  1965#  the  growth  in  computer  technology  and 
widespread  use  of  computers  by  the  government  began  to 
create  new  problems,  many  relating  to  the  rapid  technolo¬ 
gical  changes  in  the  ADP  field.  In  an  attempt  to  deal  with 
these  problems  and  "fix  responsibilities  within  the  govern¬ 
ment  for  coordinating  purchase,  lease#  maintenance,  opera¬ 
tion,  and  utilization  of  ADPE  by  federal  departments  and 
agencies".  Congress  passed  Public  Law  99-306,  commonly  known 
as  the  Brooks  Bill,  on  October  31,  1965. 


After  the  passage  of  the  Brooks  Bill,  SBCNAV  reaf¬ 
firmed  the  objectives  of  the  Havy's  ADP  program  through  the 
issuance  of  SECNAV  Instruction  10462. 7B  in  March  of  1966. 
This  instruction  reiterated  the  general  concepts,  purpose, 
and  principles  previously  addressed  in  1959. 

By  1970,  DOD  began  to  stress  improved  management  of 
the  use  of  ADP  resources  by  the  various  Military 
Departments.  Because  of  this  newly  kindled  interest  by  DOD, 
DOS  modified  their  ADP  program.  They  began  to  emphasize 
better  planning,  costing,  and  control  of  system  development. 
At  the  same  time,  the  major  program  objectives  became  more 
generalized  stating  the  need  for  the  exploitation  and  cost- 
effective  use  of  automated  data  processing  in  addition  to 
effecient  acquisition  and  management  of  its  resources 
[Ref.  5:  p-2]. 

As  more  attention  was  focused  on  the  utilization  of 
ADP  resources,  the  rules  and  regulations  that  governed  those 
resources  began  to  multiply. 

B.  LAWS  AND  REGULATIONS 
1 •  A  Feder al  Law 

Public  Law  89-306  (Brooks  Bill)  was  the  first 
substantial  attempt  to  provide  legal  guidance  to  the  govern¬ 
ment  for  the  economic  and  efficient  utilization  of  ADP 
resources.  The  bill  stipulated  that  administrative  responsi¬ 
bility  would  be  divided  among  three  separate  agencies.  The 
General  Services  Administration  (GSA)  in  a  major  role,  was 
given  authority  to  acquire,  operate,  fund,  and  dispose  of 
ADP  items  addressed  in  the  legislation.  Additionally,  GSA 
was  directed  to  act  as  the  "day-  to-day"  manager  of  all  ADP 
resource  acquisitions  [Ref.  5:  p—  2  ] .  The  Office  of 
Management  and  Budget  (OMB)  was  given  a  supervisory  role. 
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1.  Provide  Federal  Supply  Schedules  for  use  by  agencies 
in  ordering  ADPE. 

2.  Provide  technical  information  to  users  on  the  capabil¬ 
ities  and  performance  of  ADPE. 

3.  Ensure  the  efficient  utilization  of  ADPE. 

4.  Attempt  to  standardize  purchase  procedures  whenever 
possible. 

Finally,  the  circular  tasked  the  heads  of  the  various  agen¬ 
cies  with  the  responsibility  for: 

1.  Agency-wide  planning,  coordination,  and  control  of 
equipment  utilization. 

2.  Determining  ADPE  regu irement3. 

3.  Cost-effective  utilization  of  ADP  systems  by 
exploiting  or  merging  of  systems  across  organizational 
lines. 

3.  GSA  Guidelines 

Under  the  authority  granted  by  P.L.  89-306  and  OMB 
Circular  A-71,  GSA  issued  specifir  guidance  dealing  with 
acquisition  and  management  of  ADP  resources  to  all  federal 
aoencies.  The  two  primary  regulations  used  as  vehicles  to 
implement  this  guidance  were  the  Federal  Procurement 
Regulation  (FPR  Section  1-4.)  and  the  Federal  Property 
Management  Regulation  (FPSP  Section  101-35  thru  101-36). 

Since  the  provisions  of  these  regulations  are  appli¬ 
cable  to  DOD,  their  significance  to  the  management  of  the 
Navy's  ADP  program  becomes  apparent. 

a.  Federal  Procurement  Regulation 

Section  1-4  of  *he  FPR  is  totally  dedicated  to 
the  acquisition  of  ADPE,  software,  maintenance,  service,  and 
supplies.  ADPE  is  defined  by  the  FPR  as  "general  purpose 
commercially  available,  mass  produced  automated  data 


processing  components."  However,  FPMR  defines  it  as 
"general  or  special  purpose,"  which  exhibits  just  one  of 
several  inconsistencies  found  in  GSA  guidance. 

Two  subparts  within  section  1-4  of  the  fpr, 
.1103-  General  Policies  and  1104-  Procurement  Authority, 
require  additional  explanation  due  to  their  relevance  with 
the  subject  of  this  research.  Section  1-4.1103  sets  forth 
the  general  policies  for  obtaining  GSA  approval  prior  to  the 
acquisition  of  any  ADPE.  An  agency  may  only  procure  ADPE 
when  a  specific  delegation  of  procurement  authority  (DPA) 
has  been  granted  by  GSA.  However,  ADPE  may  be  acquired 
without  GSA  approval  provided  that: 

1.  The  ADPE  is  specifically  designed  for  a  specific 
application.  However,  ADPE  on  the  commercial  market 
cannot  be  acquired  under  this  exception  unless  it  is 
modified  to  such  an  extent  as  to  preclude  future  use 
of  the  equipment  for  other  purpose. 

2.  Acquisition  is  through  a  GSA  requirements  contract. 

3.  The  acquisition  cost  does  not  exceed  $50,300  [Ref.  7: 
p.  10:1-4,  1103-1]. 

On  September  8,  1978,  this  section  of  the  FPR 

was  modified  by  Temporary  Regulation  46,  "Ose  of  Small 
Purchase  Procedures  and  Schedule  Contracts  for  Automatic 
Data  Processing  (ADP)  Requirements"  ^Ref.  6:  p.  A-3].  Items 
(1)  and  (2)  were  not  changed  by  the  modification;  however, 
agencies  are  now  permitted  to  acquire  ADPE  without  prior  GSA 
approval  in  the  following  additional  instances: 

1.  If  placing  an  order  against  a  GSA  schedule  contract 
given  that: 

(a)  The  order  is  within  the  terms  and  conditions 
of  the  contract, 

(b)  The  order  is  within  the  maximum  order  limitations 
of  the  contract,  and 


(c)  The  total  purchase  price  does  not  exceed 

$300 , 000. 

2.  The  total  value  of  the  procurement  does  not  exceed 
$300,000  for  competitive  procurements  and  $50,000  for 
procurements  from  a  single  source. 

Section  1-4.1104  specifies  the  procedures  for 
requesting  GSA  approval  if  the  proposed  procurement  does  not 
fit  the  above  exceptions.  The  agency  must  submit  the 
following  information: 

1.  Copies  of  the  proposed  solicitation  document, 

2.  Estimated  dollar  value  of  the  procurement, 

3.  Estimated  system  life, 

4.  Location  of  the  data  processing  facilities  involved, 

5.  The  fiscal  quarter  during  which  the  solicitation  is 
expected  to  be  released, 

6.  A  listing  of  any  unique  support  requirements, 

7.  A  statement  that  an  evaluation  has  been  made  to  ensure 
that  the  the  proposed  procurement  represents  the 
lowest  overall  cost  alternative  to  meet  the  need, 

9.  Evidence  whether  or  not  site  construction  is  required, 

9.  A  statement  that  the  need  to  document  ADPE  has  been 
documented, 

10.  Statement  that  all  available  resources  have  been 
screened  and  none  are  available  to  meet  the  agency's 
need,  and 

11.  A  thorough  and  compLate  justification,  if  applicable, 
of  the  requirement  for  a  sole  source  acquisition 

fHef.  7:  p.  1-4.1104]. 

GSA  has  three  options  in  dealing  with  an  agency 
procurement  request  (APR)  .  First,  they  can  delegate  the 
authority  to  procure  the  ADPE  to  the  requesting  agency. 
This  is  what  was  refarad  to  above  as  a  delegation  of 
procurement  authority  (DP A ) .  Secondly,  they  can  issue  a 
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Dpi ,  bat  require  that  GSA  aaintains  some  type  of  involvement 
in  the  acquisition.  Finally,  GSA  oar.  conduct  the  acquisi¬ 
tion  themselves.  Irrespective  of  GSi's  option,  action  must 
be  initiated  within  twenty  working  days  or  the  requesting 
agency  may  assume  that  a  DPi  has  been  granted. 

b.  Federal  Property  Management  Regulation 

Sections  101.35  and  101.36  provide  the  proce¬ 
dures  pursuant  to  GSi’s  function  as  the  '’day-to-day"  manager 
of  all  federal  ADP  acquisitions.  Ihe  regulation  discusses 
such  matters  as  leasing  equipment,  reutilization  of  excess 
ADP  E,  Federal  Software  Exchange  Program,  and  the  ADP 
revolving  fund.  Additionally,  the  regulation  requires  that 
each  APS  for  systems  estimated  at  over  $100,000  be  accompa¬ 
nied  with  a  well  documented  system  study.  This  study  should 
demonstrate  that: 

1.  The  functions  to  be  performed  are  essential  and 
readily  adaptable  to  automation, 

2.  An  effort  was  made  to  reduce  the  workload  of  the 
activity  before  proceeding  with  an  expansion  of 
capacity, 

3.  An  interim  upgrade,  software  modification,  or  schedule 
changes  cannot  be  accomplished  to  improve  perfor¬ 
mance, and 

4.  The  new  system  design  will  achieve  the  highest 
possible  effectiveness  [Ref.  8:  p.  19]. 

Although  GSA  issues  a  multitude  of  directives 
dealing  with  ADP  resources,  there  are  two  additional  docu¬ 
ments  that  should  be  mentioned.  First,  the  Federal 
Management  Circular  provides  general  ADP  policies  to 
federal  agencies,  but  supplies  no  specific  procedures. 
Secondly,  GSA  issues  Temporary  Regulations  which  provide 
interim  changes  to  the  FPS  and  FPSR  [Ref.  6:  p.  A-3  ]. 


It  is  within  the  framework  of  the  regulations 
previously  discussed  that  DOD  and  DON  must  conduct  the 
acquisition  and  management  of  ADP  resources.  In  this 

regard,  DOD  and  DON  have  issued  a  myriad  of  instructions  and 
directives  to  provide  further  guidance  in  the  effective  and 
efficient  management  and  acquisition  of  ADP  resources. 

4 .  SOD  Guidelines 

Upon  reviewing  the  numerous  guidance  promulgated  by 
DOD,  it  is  apparent  that  two  instructions  are  extremely 
significant  within  the  scope  of  this  research.  These 
instructions  deal  with  the  acquisition  and  management  of  ADP 
resources. 

a.  DOD  Instruction  5100.40 

DOD  Instruction  5100.40  entitled 

"Responsibilities  for  the  Administration  of  the  Automatic 
Data  Processing  Program",  was  issued  in  1970.  This  instruc¬ 
tion  designated  the  Assistant  Secretary  of  Defense 
(Comptroller)  as  the  administrator  of  the  DOD  ADP  program. 
His  responsibilities  include  developing  program  policies, 
criteria,  and  standardization  of  ADP  resources  throughout 
the  Defense  Departments.  The  Service  Secretaries  were 
required  to  designate  a  Senior  ADP  Policy  Offical  (SPO) . 
The  SPO  was  responsible  to  evaluate  ADP  systems  before 
implementation  in  hopes  of  promoting  effective  selection, 
acquisition,  and  reutilization  of  ADPE. 

b.  DOD  Directive  4  105.55 

DOD  Directive  4  105.55  (dated  Nay  19,  1972)  enti¬ 
tled  "Selection  and  Acquisition  of  Automatic  Data  Processing 
Resources",  established  policies  and  guidance  for  the  selec¬ 
tion  and  acquisition  of  ADPE,  computer  programs,  ADP 
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contractual  services,  and  supplies.  The  directive  stipulated 
that  the  decision  to  acquire  ADP  resources  will  be  contin¬ 
gent  on  a  well  documented  study,  demonstrating  that: 

1.  A  valid  information  requirement  exist. 

2.  The  function  or  process  to  be  performed  is  essential. 

3.  Ose  of  ADP  resources  is  the  most  cost-effective  method 
for  the  performance  of  the  function. 

U.  The  ADP  system  will  be  designed  to  provide  the  highest 
practicable  degree  of  effectiveness  and  operational 
economy. 

5.  The  lowest  overall  cost  alternative  satisfying  the 
requirement  is  determined  prior  to  +he  selection  and 
acquisition  of  ADP  resources. 

Prior  to  acquiring  any  replacement  ADPE,  consid¬ 
eration  of  automated  data  system  design  or  redesign  is 
required.  This  enables  the  services  to  exploit  the  existing 
capabilities  of  ADPE.  Ose  of  commercial  sources  for  selec¬ 
tion  and  acquisition  of  ADP  resources  is  not  permitted 
unless  sharing  or  reutilizing  existing  government  ADP 
resources  is  uneconomical  or  unsatisfactory.  The  directive 
further  requires  tha  :  development  of  system  specifications 
and  requirements  must  be  independent  of  a  particular 
vendor's  product  to  avoid  unfair  acquisition  practices. 

Selection  of  ADPE  for  multiple  installations  is 
initiated  when  the  system  to  be  used  is  centi  '  y  designed, 
programmed,  and  maintained  for  installations  concerned.  The 
directive  states  that  in  this  case,  a  prototype  installation 
will  be  selected  for  initial  system  implementation.  The 
remaining  sites  will  not  receive  the  system  until  the  proto¬ 
type  system  has  adequately  performed  in  its  operational 
environment  and  has  been  reviewed  and  certified  through 
established  evaluation  criteria. 


In  an  effort  to  promote  effective  selection  and 
acquisition  of  ADP  resources,  the  directive  required  that 
each  military  department  establish  a  professionally  staffed 
activity.  The  activity  would  be  tasked  with  developing 
solicitation  documents,  evaluating  vendor  proposals,  and 
performing  competitive  selection  of  ADPE  exceeding  an  esti¬ 
mated  value  of  $200,000  if  the  equipment  was  leased  and 
$500,000  if  purchased.  inquisition  of  ADPE  estimated  at  a 
lower  value  would  be  administered  by  the  requesting 
activity.  Additionally,  the  directive  specified  that 
service  secretaries  were  responsible  for  approving  the 
selection  of  ADP  resources.  This  authority  could  be  dele¬ 
gated  only  on  acquisitions  estimated  below  $500,000. 

5  •  Mil  Guidelin  es 

Desiring  to  provide  internal  guidelines  for  review, 
approval,  and  procurement  of  ADP  resources,  the  Assistant 
Secretary  of  the  Navy  for  Financial  Management  (SPO,ADP) 
sponsored  several  instructions.  Today,  guidelines  have  been 
promulgated  for  such  things  as  data  element  and  code  stand¬ 
ardization,  programming  language  standardization,  ADP 
sharing,  ADP  equipment  reutilization,  and  the  management  of 
automated  data  systems  development  just  to  name  a  few.  The 
NA7DAC  (Naval  Data  Automation  Command)  Instruction  5230.2 
lists  over  40  SECNAV  (Secretary  of  the  Navy)  Instructions 
for  ADP  resource  management. 

Perhaps  the  most  important  instruction  that  influ¬ 
enced  and  guided  the  procedure  used  to  automate  the  procure¬ 
ment  process  of  the  NFCS  was  SECNAVINST  5236. 1A  entitled 
"Specification,  Selection,  and  Acquisition  of  Automatic  Data 
Processing  Equipment  (ADPE)",  dated  30  April  1974.  The 
instruction  was  the  Navy’s  product  of  implementing  the  ADP 
directives  provided  by  0M3,  GSA,  and  DOD.  The  instruction 
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also  delineated  the  responsibilities  of  the  DIR  DON  ADPM, 
OP-942,  and  the  Automatic  Data  Processing  Equipment 
Selection  Office  (ADPESO). 

The  DIR  DON  ADPM  was  directly  responsible  to  the  SPO 
for  developing  and  promulgating  plans,  policies,  and  proce¬ 
dures  with  respect  to  ADP  review  and  evaluations.  He  was 
also  designated  as  the  Source  Selection  Authority. 

ADPESO,  later  designated  ADPSO,  was  established  as  a 
direct  result  of  DODINST.  4  105.55  requiring  the  formation  of 
a  professionally  staffed  activity  within  each  service. 
Initially,  ADPESO  was  responsible  for  acquisition  of  only 
ADPE,  but  eventually  they  assumed  responsibility  for  soft¬ 
ware,  services,  and  supplies.  They  were  also  tasked  with 
functioning  as  the  primary  DON  liaison  office  for  ADPE 
acquisition  matters. 

The  instruction  reaffirmed  the  original  program 
policy  of  conducting  studies  prior  to  the  acquisition  of  ADP 
resources.  It  emphasized  that  developing  data  processing 
systems  and/or  acquiring  computer  equipment  must  be  preceded 
by  studies  which  form  the  basis  for  (1)  identifying  informa¬ 
tion  requirements,  (2)  determining  the  kind  of  system 
needed,  and  (3)  developing  specifications  to  select  and 
acquire  computer  equipment. 

The  approval  authority  and  associated  monetary 
thresholds  were  also  established  by  this  instruction.  The 
levels  of  approval  required  was  based  upon  the  monetary 
value  of  the  equipment  and  the  type  of  procurement  action 
(competitive  or  sole  source).  On  12  April  1977  these 
approval  levels  and  thresholds  were  modified  by  SECNAVNOTE 
5230.  The  levels  and  thresholds  are  shown  by  Figure  3.1. 

These  then  are  the  major  instructions  and 
regulations  that  governed  the  management  and  acquisition  of 
ADP  resources  during  the  initial  stages  of  the  effort  to 
automate  the  NPCS  procurement  process. 
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Type  Approval 
A.  General  Purpose  ADPE 
(Sole  Source) 
exceeds  $500,000  purchase  X 
Op  to  $500,000  purchase 
Op  to  $1  00,000  purchase 
(non-CP  0) 


Level  2  Level  3 


B. 


General  Purpose  ADPE 
(Competitive) 

Exceeds  $  1 M  purchase 
Op  to  $  1 M  purchase 
Op  to  $200,000  purchase 
(non-CPU) 

Op  to  $100,000  purchase 
(including  CPU) 


X 


X 

X 


Le  ve  1  1 

Assistant  Secretary  of  the  Navy  (Financial  Management) 


Level  2 

Chief  of  Naval  Operations 
Director,  DON  ADP  Management 
Commandant  of  the  Marine  Corps 


L©  vg  1  3 

Deputy  Comptroller  of  the  Navy 

Director  of  Civilian  Personnel 

Chief  of  Naval  Research 

Chief  of  Naval  Material 

Chief,  Bureau  of  Medicine  and  Surgery 

Commander,  Navy  Military  Personnel  Command 

Commander  in  Chief,  0. S .  Atlantic  Fleet 

Commander  in  Chief,  0.  S .  Pacific  Fleet 

Commander  in  Chief,  0. S.  Naval  Forces,  Europe 

l. _ _  _ _ — -  — . . . . . - ... _ _ 1 


Pigure  3.1  DON  Approval  Levels  and  Thresholds  for  ADP 
(Ref.  8) 


C.  PROCESS  FOR  ACQUIRING  ADP  RESOURCES 

It  should  be  quite  evident  at  this  point  that  there  are 
two  separate  sequential  processes  for  acquiring  an  ADP 
system  within  the  Navy.  The  first  requires  that  the 
requesting  command  analyze  and  justify  the  proposed  system. 
This  involves  exhibiting  that  the  system  iee*s  an 


operational  requirement  and  then  justification  of  the 
system's  technical  and  economical  viability.  The  Navy's 
vechicle  for  providing  justification  in  conjuction  with 
system  planning  is  called  an  Automated  Data  System 
Development  Plan.  The  plan  has  two  parts.  The  first  part 
develops  and  presents  the  economic  analysis.  The  second 
part  is  a  milestone  progress  report.  Captain  Jan  Prokop  in 
his  book.  Computers  in  the  Navy,  describes  the  plan  as 
follows: 
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d  [Ref.  9:  p.  30]. 


The  level  at  which  this  plan  is  reviewed  and  approved 
depends  upon  the  cost  of  the  system  and  the  command  sponsor¬ 
ship  or  proponent's  ability  to  generate  high-level  interest 
in  the  system.  This  is  a  very  significant  point  due  to  the 
Navy's  effort  in  the  late  70's  to  centralize  the  decisions 
regarding  ADP  policy  and  delegating  the  responsibility  for 
implementation  and  reviaw  to  the  operational  commanders. 
Systems  receiving  high-level  review  cause  periods-  manage¬ 
ment  reviews  of  alternatives,  incurred  cost,  and  milestones. 
This  adds  to  increased  effectiveness  in  the  acquisition  of 
ADP  resources.  On  the  other  hand,  a  low  interest-low  cost 
system  is  not  afforded  the  necessary  management  review  to 
ensure  effective  use  of  these  valuable  resources.  Sometimes 


this  is  on?  of  the  major  reasons  that  systems  fail  to 
perform  as  originally  planned. 

Upon  approval  of  the  plans,  the  second  process  begins: 
the  evaluation  and  selection  of  the  equipment.  If  authority 
to  acquire  the  ADPE  is  granted  by  3S A  (DPA)  or  it  comes 
under  the  exceptions  previously  listed,  ADPSO  will  normally 
accomplish  the  selection  and  acquisition  of  ADP  resources 
requiring  Level  I  or  Level  II  approval.  NAVSOP  has  desig¬ 
nated  other  activities  which  can  procure  ADPE.  These  activ¬ 


ities  are  the  NHCC's  in  Washington,  D.C.  and  Long  Beach, 
Ca. ;  and  local  purchasing  offices  of  the  Naval  Material 


IV.  £H  E  AUTOMATION  EFFORT 


A.  BACKGROUND 

As  perviously  mentioned  in  Chapter  One,  NAVSUP  first 
initiated  actions  to  automate  the  procurement  process  at  the 
major  NFCS  activities  in  late  1974,  However,  they  were  by 
no  means  the  first  source  to  advocate  or  use  ADP  resources 
for  the  procurement  function.  As  early  as  1961,  Howard  T. 
Lewis,  professor  emeritus  of  the  Harvard  Graduate  School  of 
Business  Administration,  when  describing  the  future  of  the 
purchasing  process  stated,  "There  will  be  big  changes  in 
dealing  with  stock,  inventory,  and  order-placing  responsi¬ 
bilities.  This  will  come  about  as  a  result  of  better 
management  comprehension  of  the  nature  and  relationship 
between  these  activities,  and  a  greater  use  of  automatic 
data  processing"  (Hef.  10:  p.  15  ].  Again  in  1964,  J.  Weding 
and  C.  Diamond  addressed  the  issue  in  their  article,  "Buy  by 
Computer",  published  in  the  Harvard  Business  Review  that 
year.  They  indicated  that  relative  to  other  functions 
within  industry  and  government,  the  procurement  function  had 
consistently  been  slow  to  apply  modern  management  techni¬ 
ques;  therefore,  use  of  ADP  resources.  They  further  indi¬ 
cated  that  the  procurement  organization  should  design, 
operate,  and  control  their  own  automated  system  sc  as  to 
obtain  the  type  of  information  important  for  effective 
procurement  management  [Ref.  11;  p.  109]. 

In  1966,  Achelleas  Kollios  and  Joesph  Stempel  in  their 
book,  Pu££h££*&SL  and  EDP,  discussed  the  issue  of  utilizing 
EDP  in  the  purchasing  function.  In  particular,  they 
described  in  detail  the  integrated  automated  procurement 
system  used  at  the  Aviation  Supply  Office  (ASO) .  This 
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system  basically  consisted  of  an  automated  ordering  function 
integrated  with  financial  and  inventory  management  control 
programs  [Ref.  10:  pp.  69-90]. 

On  4  September  1969,  NSC  San  Diego  implemented  an 
Automated  Local  Purchase  Support  system  (ALPS).  The  system 
consisted  of  three  major  data  files;  (a)  FSN/Part  Number 
File,  (b)  Supplier  Name  and  Address  Pile,  and  (c)  Automated 
Follow-up  File.  The  system  automated  the  purchasing  of  cont¬ 
rolled  local  purchase  items  and  items  under  existing 
contracts  [Ref.  12:  p.8]. 

By  October  the  following  year,  the  small  purchasing 
function  at  various  NSC*  s  was  being  automated  through 
locally  developed  systems.  However,  none  of  these  systems 
could  be  classified  as  a  complete  integrated  procurement 
management  information  system.  During  this  time  period,  the 
Fleet  Material  Support  Office  (FMSO),  having  overall  respon¬ 
sibility  for  design  of  uniform  automated  data  processing 
procedures  and  programs,  initiated  work  on  a  system  that 
would  integrate  the  fragmented  programs  of  various  activi¬ 
ties  into  a  comprehensive  information  system.  The  system 
would  be  divided  at  three  different  levels;  (a)  Inventory 
Control  Points,  (b)  Navy  Stock  Points,  and  (c)  Fleet  Units. 
The  development  of  one  system  applicable  to  these  three 
levels  was  considered  to  be  beyond  the  scope  of  the 
resources  available  at  that  time  [Ref.  13:  p.125]. 

Another  example  of  automating  a  procurement  process  was 
exhibited  by  Lieutenant  Kenneth  Patterson,  SC,  USN,  in  his 
master's  thesis  titled,  "An  Inf oc ma tior.  System  for  the 
Management  fo  Navy  Procurement".  LT.  Patterson  proposed  a 
model  that  attempted  to  solve  problems  that  procurement 
managers  have  in  accumulation,  digestion,  and  dissemination 
of  procurement  information  [Ref.  13:  p.125].  The  system  was 
called  ASPIRB  which  is  the  acronym  for  Automated  Status  of 


Purchase  Information  Recorded  Electronically.  It  was  envis- 
sioned  that  ASPIRE  would  be  a  totally  integrated  system, 
exportable  to  all  procurement  activities.  Subsequent  to  the 
publishing  of  LT.  Patterson's  thesis,  ASPIRE  was  implemented 
at  NSC  Puget  Sound  in  Bremerton,  Washington  to  undergo 
testing. 

As  ■'■he  market  for  electronic  data  processing  equipment 
and  software  began  to  expand,  so  did  the  number  of  systems 
used  by  NFCS  major  activities  for  the  purpose  of  procure¬ 
ment.  Thera  was  PRONIS  (Procurement  Management  Information 
System)  used  at  NSC  Charleston  and  the  WANG  system  used  a 
NRC 0  Long  Beach,  in  addition  to  ASPIRE  at  NSC  Puget  Sound 
and  ALPS  at  San  Diego.  As  the  internal  and  external 
requirements  increased  and  the  benefits  of  automation  became 
known,  procurement  managers  began  to  automate  the  procure- 
men*  process  at  their  activities.  This  led  to  various  unre¬ 
lated  systems,  none  of  which  were  totally  integrated. 

By  1974,  NAVSOP  began  exploring  alternatives  to  improve 
the  total  responsiveness  of  the  procurement  process  in  addi¬ 
tion  to  resolving  the  continued  personnel  reductions 
plaguing  the  various  supply  activities.  Automation  of  the 
procurment  process  at  the  NFCS  activities  was  considered  to 
be  one  alternative  solution  to  their  problems.  In  recogni¬ 
tion  of  this  alternative,  NAVSOP  initiated  several  efforts 
to  develop  an  automated  procurement  system,  refersd  to  as 
APADE  (Automation  of  Procurement  and  Accounting  Data  Entry 
System)  . 

B.  APADE  I 

In  April  of  1975,  a  funded  research  and  development 
project  was  initiated  at  two  pilot  test  sites  to  determine 
the  feasibility  and  cost  effectiveness  of  converting  the 
existing  manual  process  of  preparing  formal  procurement 
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documents  to  an  automated  system  utilizing  a  minicomputer. 
The  test  sites  selected  were  two  inventory  control  points; 
Aviation  Supply  Office  (ASO)  and  Ships  Part  Control  Center 
(SPCC)  . 

1 •  System 

The  research  and  development  effort  consisted  of 
using  Data  General  Nova  800  minicomputers  foe  procurement 
document  preparation.  They  were  mainly  RFP's,  IFB's,  and 
purchase  award  documents.  The  system  worked  by  a  typist 
interacting  with  the  minicomputer  through  the  use  of  a  CRT 
display  unit.  The  operator  would  answer  various  guestions 
that  were  programmed  for  each  type  of  document.  The  informa¬ 
tion  would  then  be  printed  out  by  a  large  Spectra  70 
printer.  This  printed  document  had  to  be  reduced  before 
being  mailed  out  to  the  contractors. 

2 •  Results 

The  R&D  project  met  with  only  limited  success. 
However,  the  test  indicated  that  the  potential  existed  for 
greater  improvements  in  this  area  as  well  as  in  other  labor 
intensive  procurement  functions. 

As  and  outgrowth  of  the  R5D  project,  NAVSOP  tasked 
FMSO  in  December  1975  to  review  locally  developed  automated 
purchase  systems  at  various  MFCS  and  other  DOD  activities  in 
addition  to  commercial  sources  for  possible  standardize* ion 
and  exportation  to  the  NFCS.  The  following  is  a  list  of 
those  systems  evaluated; 

1.  PBOaiS  -  NSC  Charleston’s  Procurement  Management 

Information  System, 

2.  ASPIR2  -  NSC  Puget  Sound’s  Automated  Status  of 

Purchasing  INformation  Recorded  Electronically, 

3.  HANG  System  -  NRCO  Long  Beach’s  procurement  system, 
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SAMMS  -  Defense  Logistics  Agency's  standard  Automated 
Material  Management  System, 

5.  PADS  -  DAHCOM's  Procurement  Automated  Documentation 
System, 

6.  Cl APS  -  Air  Force's  Customer  Integrated  Automated 
Procurement  System, 

7.  MOHAWK  Data  Sciences  21/50  System, 

8.  IBM  PROFS  Micro  Computer  System, 

9.  WANG  Data  Processing  and  Word  Processing  "Vs"  System, 
and 

10.  Xerox's  860  Word  Processing  System. 

FMS 0  reported  that  these  unique  purchase  systems  were  not 
sufficiently  comprehensive  and  that  exportation  of  any 
existing  system  was  not  feasible,  even  for  a  short  term. 

Following  the  system  review,  the  need  for  the  design 
and  development  of  an  automated  procurement  system,  which 
addressed  the  total  needs  of  the  NFCS  activities  became 
apparent.  In  1976,  fiscal  year  1977  funds  were  granted  under 
the  Navy  Productivity  Enhancement  Program  to  develop  APAD5 
for  system-wide  application. 

C.  APADE  II 

1  •  Project  Initializat  ion 
a.  Command  Plan  #  338 

In  April  1977,  NAVSUP  02,  Deputy  Commander  for 
Procurement  Management,  submitted  Command  Plan#  338, 
Automation  of  Procurement  and  Accounting  Data  Entry  (APADE), 
to  the  Commander  Naval  Supply  Systems  Command. 
Subsequently,  the  plan  was  revised  and  resubmitted  on  13 
June  1977. 

The  purpose  of  the  plan  was  to  provide  manage¬ 
ment  information  concerning  the  project.  The  overall  goal 
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of  the  project,  as  stated  by  the  plan,  was  to  provide  an 
automated  procurement  management  system  to  major  field 
procurement  activities.  Specifically,  the  plan  stated  that. 

The  APADE  project  will  provide  an  automated  procurement 
management  system  to  11  NA7SUP  procurement  activities 
and  18  o^her  major  field  purchasing  activities  with 
capabilities  for  PB/requisition  tracking,  automated 
document  preparation,  and  management  information 
reports.  yhe  system  will  also  have  source  data  automa¬ 
tion  capabilities  to  enable  transfer  of  pertinent 
procurement  data  to  interfacing,  dependent  financial  and 
supply  data  systems  without  manual  intervention. 
Overall  effect  will  be  to  improve  field  procurement 
function,  reduce  cost  of  orocurement  operation,  reduce 
procurement  administrative  lead  time,  provide  more 
responsive  support  to  NFPS  (NFCS)  customers. 

Additionally,  the  plan  listed  the  following 
tasks  which  contribute  to  accomplishment  of  the  goal: 

1.  Finalize  system  policy  concepts, 

2.  Develop  system  design  specifications, 

3.  Identify  hardware  requirements  and  software  require¬ 
ments, 

4.  Develop  requirements  documentation, 

5.  Obtain  hardware  requisition  approval, 

6.  Procure  hardware/software, 

7.  Test  and  implement  at  prototype  site, 

8.  Implement  at  remaining  SA7S0P  activities,  and 

9.  Implement  at  designated  non-NAVSOP  activities. 

The  Command  Plan  specifically  tasked  FMSO  with  providing 
analysis,  contracting,  implementation  and  maintenance 
support  for  the  APADE  project.  A  copy  of  the  revised 
Command  Plan  is  provided  in  Appendix  3. 

Upon  reviewing  this  plan,  it  is  evident  that  the 
drafting  of  the  system  design  specifications  was  estimated 
to  take  only  one  month.  Additionally,  the  total  system 
development,  including  acquisition  of  all  applicable  hard¬ 
ware  and  software,  was  estimated  at  six  months  with  testing 
and  implementation  at  the  prototype  site  to  be  completed 
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only  nine  months  after  project  initialization.  These  appear 
to  be  unrealistically  short  time  frames,  given  the  myriad  of 
higher  agency  requirements  discussed  in  Chapter  III. 

b.  Organization 

Following  the  initial  submission  of  Command 
Plan#  338,  the  general  management  responsibilities  within 
the  various  commands  began  to  formalize.  The  responsibility 
of  functional  sponsor  for  the  APADE  project  was  assigned  to 
Deputy  Commander  for  Contracting  Management  (NAVSUP  02). 
Project  Management  was  assigned  to  the  Deputy  Commander  for 
Plans,  Policy,  and  Programs  Development,  Financial  Systems 
Development  Division  (NAVSUP  044)  .  This  Division  would  be 
responsible  for  planning,  funding,  executing,  and  monitoring 
APADE  II  development,  initial  implementation  and  system 
maintenance.  NAVSUP  041,  Programs  Control  and  Development 
Division  would  provide  support  by  scheduling  and  performing 
automated  data  processing  reviews  and  assisting  in  the 
preparation  of  various  development  plans. 

FMSO,  as  the  NA  VSUPS YSCON  agency  responsible  for 
design  of  uniform  automated  data  processing  procedures  and 
programs,  would  perform  the  technical  management  of  the 
project.  They  would  be  specifically  tasked  with  ensuring 
that  the  Functional  Description  ( FD»  and  Data  Requirements 
Document  (DRD)  accurately  reflected  the  needs  of  the 
procurement  community  and  were  precise  enough  to  aid  in 
system  development.  Additional  responsibilities  included 
those  addressed  in  the  Command  Plan. 

c.  Systems  Policy  and  Concepts 

As  required  by  the  Command  Plan,  NAVSUP  02 
published  the  Systems  Policy  and  Concepts  Policy  document  in 
Aprill  1977.  The  purpose  of  this  document  was  to  outline 


53 


the  requirements  for  the  APADE  II  system.  The  document 
included  the  following  main  features: 

1.  Purchase  request  (PR)/  requistion  traclcing/document 
control, 

2.  Automated  preparation  of  standardized,  formal  procure¬ 
ment  documentation, 

3.  Source  data  automation, 

4.  Procurement  management  information  reporting, 

5.  Procurement  interface  with  existing  data  systems,  and 

6.  Seal  time,  interactive  processing. 

Additionally,  this  docunent  specifically  stated 
that,  "APADE  II  will  provide  a  standardized  baseline  for 
automation  of  procurement  processes  throughtout  the  Navy 
Field  Procurement  System.  Due  to  the  broad  range  of  activi¬ 
ties  involved  and  the  significant  differences  in  existing 
interrelated  (e.g.  supply  and  financial)  management  systems 
in  operation  at  various  activities,  APADE  II  design  must  be 
sufficiently  flexible  to  accommodate  such  factors"  [Ref.  14: 
p.  3-4], 

d.  ADS  Development  Plan 

In  addition  to  the  System  Policy  and  Concepts 
document,  NA7S0P  also  initiated  wort  on  the  Automated  Data 
System  Development  Plan  during  the  same  time  frame. 
However,  this  document  was  not  officially  approved  by  the 
CND  until  12  October  1977.  This  document,  as  discussed  in 
Chapter  Three,  provided  the  justification  of  the  system's 
technical  and  economical  viability. 

The  first  part  of  the  ADS  plan  was  the  Economic 
Analysis.  In  analyzing  the  automation  of  the  procurement 
process,  five  alternatives  were  considered.  They  were: 
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Continue  current  system. 


2.  Contract  service, 

3.  Share  or  use  existing  facilities, 

4.  Develop  a  central  procurement  system,  and 

5.  Develop  a  uniform  minicomputer  system  at  each  proposed 
site. 

Alternative  One  was  eliminated  since  it  had 
previously  been  shown  that  the  curant  system  was  slow  and 
severly  impacted  upon  the  responsiveness  of  the  system.  The 
second  alternative  was  not  feasible  because  APADE  II  was 
intended  for  operation  by  ncn-ADP  personnel  with  minimal 
training  required  for  system  operation.  It  was  further 
estimated  that  system  operation  would  not  exceed  0.5  person 
hours  per  activity  per  day.  Therefore,  it  was  not  practical 
to  contract  for  this  small  work  load.  Additionally,  it  was 
planned  that  software  maintenance  and  enhancements  would  be 
performed  by  FMSO.  Alternative  Three  was  eliminated  since 
existing  facilities  were  considered  to  be  saturated  and  did 
not  allow  the  objectives  of  the  system  to  be  met. 

Both  Alternatives  Four  (4)  and  Pive  (5)  were 
considered  to  provide  equal  benefits;  however,  the  central 
procurement  system,  alternative  4,  would  require  additional 
manpower  for  system  operation  in  addition  to  expanded  facil¬ 
ities  for  environmental  protection.  Alternative  4  was 
eliminated  as  the  greater  cost/equal  benefit  alternative. 

Alternative  5  consisted  of  locating  minicompu¬ 
ters  at  12  operational  sites  plus  one  test  bed  minicomputer 
site.  The  software  would  be  uniform  across  the  procurement 
system.  The  systam  would  be  adaptable  to  volume  and  varying 
personnel  requirements  at  the  sites.  Each  system  would  have 
one  central  processor  with  256K  memory,  multiple  disk  units 
with  up  to  10M  bytes  of  storage,  one  magnetic  tape  unit,  one 
card  reader,  one  to  two  line  printers,  and  up  to  4  ca*hode 
ray  terminals.  The  software  developers  would  provide 
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turnkey  programming  training  and  would  be  required  only  for 
maintenance  at  FMSO.  Some  operational  training  was  consid¬ 
ered  to  be  necessary,  but  the  system  could  be  operated  by 
existing  employees  currently  in  the  activities.  The  system 
would  also  produce  tapes  which  would  interface  to  other  data 
bases  affected  by  procurement  operations. 

Specifically,  APADE  II  would  be  capable  of 
interfacing  with  certain  existing  supply,  financial,  and 
contract  administration  systems  as  necessary.  These  systems 
include:  Uniform  Automated  Data  Processing  System 
(UADPS-SP)  ,  Naval  Sea  Systems  Management  Information  System 
(NAVSEAMIS) ,  Navy  Uniform  Vendors  Evaluation  Program 
(NUVEP)  ,  Military  Standard  Contract  Administration  Procedure 
(MILSCAP),  Shipboard  Uniform  Automated  Data  Processing 
System  (SUADPS)  ,  and  the  Integrated  Disbursing  and 
Accounting  Data  Exchange  (IDA-DX). 

The  equipment  would  require  no  special  environ¬ 
ment.  The  CRTs  would  be  placed  on  desk,  utilizing  existing 
work  space.  The  central  processing  unit  (CPU)  ,  disk,  and 
magnetic  tape  units  would  be  mounted  on  racks.  Lina  prin¬ 
ters  would  be  located  near  the  supervisor's  office. 
Overall,  Alternative  5  was  designed  to  meet  the  needs  of  an 
automated  procurement  system  in  the  areas  of: 

1.  Procurement  operations, 

2.  Report  generation, 

3.  Document  preparation,  and 

4.  source  data  automation. 

The  total  cost  of  the  minicomputer  system  was 
estimated  at  $159.9  million,  shown  in  Table  I.  Based  upon 
an  inflation  rate  of  4.7  percent  per  year,  the  total  present 
value  savings  was  estimated  at  $4,  265  million  over  the 
estimated  eight  year  life  of  the  system.  Payback  of  the 
investment  was  calculated  at  1.97  years. 
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r ABLE  I 


COST 

Type 


APAOB 


1 


APADE  Estimated  Cost 

♦APADE  11-Project  Years 
2  3  4  5  6 


Total 


8 


Development 

ADP  .  3  0  3  0  0  0  0  0  .3 

Non- ADP  00000000  0 

Operational 

ADP  .  09  16.5  17.  3  18.2  18.  9  19.8  20.  8  21.8  22.8  156.3 
Non- ADP  .  04  .2  .  2  .  2  .3  .3  .3  .3  .3  2.1 

Equipment. 11  1.4  0003000  1.4 


Total 

System  .  24  18.4  17.  5  18.4  19.2  23.1  21.1  22.1  23.1  159.8 


*  Inflated  at  4.77c  per  year  (CHNAVMAT  ltr.  26  Oct.  1976) 


The  economic  analysis  exhibited  that  Alternative 
5  provided  for  automation  of  most  procurement  operations  at 
a  relatively  low  cost  for  equipment,  software,  and  support. 

In  conducting  the  economic  analysis,  the  ADS 
development  plan  projected  a  starting  date  of  the  first 
quarter  fiscal  year  1978.  Project  completion  was  estimated 
at  ADS  approval  plus  18  months.  Figure  4.1  provides  the 
planned  ADS  locations  with  installation  date  and  ADPE  to  be 
utilized. 

The  second  part  of  the  ADS  Development  Plan 
consisted  of  the  Milestone  Progress  Report.  This  report 
exhibited  the  same  proposed  task  and  completion  dates  as  did 
Command  Plan#  338,  Appendix  B. 
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Figure  4.1  Site  Location  and  Installation  Estimates  (ADS 
Development  Plan) 


2 •  Project  Appro val  and  Ta sking 

On  8  June  1977,  SAVSOP  044  reemphasized  to  FMSO  the 
following  required  actions: 

1.  Develop  system  design  specifications  by  1  June  1977, 

2.  Award  a  contract  by  6  June  1977  to  identify  hardware 
and  software  requirements, 

3.  Identify  hardware  and  software  requirements  by  15  July 
1977, 

4.  Develop  requirements  documentation  by  30  July  1977, 

5.  Procure  hardware/software  by  3D  September  1977, 

5.  Implement  and  test  at  NSC  Oakland,  and 


7.  Implement  at  remain-, ng  stock  points  by  30  September 
1978. 

Additionally,  MAVSOP  044  classified  the  project  as  mandatory 
with  an  assigned  priority  of  7a.  This  priority  indicated 
that  the  APADE  effort  was  part  cf  another  major  project  that 
was  seventh  on  a  priority  list  of  projects  assigned  and 
approved  for  FMSO  during  that  fiscal  year. 

On  30  June  1  977,  the  Assistant  Deputy  Commander, 
Plans,  Policy  and  Program  Development,  NATSO?  049,  forwarded 
the  approved  Command  Plan  I  338  to  FMS0*s  Commanding  Officer 
for  assignment  of  the  responsibilities  and  tasks  as  previ¬ 
ously  mentioned.  NAVSOP  04  9  emphasized  the  fact  that  NAVSOP 
04  was  responsible  for  project  completion  and  sucess  of  the 
program  hinged  on  the  ability  of  NAVSOP  to  contract  for 
hardware  by  30  September  1977. 

3.  Hardware  Acqu isitio n 

* 

On  26  July  1977  a  delivery  order  contract  was  issued 
to  Systems  Consultants,  Inc.  (SCI)  as  a  result  of  an  unsoli¬ 
cited  proposal  from  SCI  to  FMSD .  The  contract  specifically 
requested  that  SCI  perform  the  following  action  if  optioned 
by  the  Government: 

1.  Participate  in  technical  conferences  with  FMSO 
personnel , 

2.  Review  APADE  II  design  specifications, 

3.  Develop  specific  equipment  and  system  requirements, 

4.  Perform  a  survey  of  all  available  minicomputers  suita¬ 
ble/capable  of  performing  this  task,  and 

5.  Prepare  a  full  system  specification. 

With  the  exception  of  task  five,  ail  actions  were  optioned 
and  completed.  SCI  provided  a  set  of  general  system  speci¬ 
fication  instead  of  full  system  specification  as  outlined 
abo  ve . 


As  a  result  of  the  information  provided  by  SCI,  FMSO 
informed  NAVSUP  049  that  APADE  II  hardware  requirements  had 
been  identified  on  16  August  1977.  The  hardware  selection 
was  based  upon  a  comparative  analysis  of  minicomputer 
systems  from  the  following  commercial  manufacturers: 

1.  Data  General, 

2.  Interdata, 

3.  Varian,  and 

4.  DEC 

The  equipment  selected  was  the  Interdata  System. 
This  system  consisted  of  a  7/32  oentral  processing  unit 
(256K  Bytes),  22M  Bytes  disk  drives,  600  lines  per  minute 
printers,  400  cards  per  minute  card  readers,  and  video 
display  units.  Additionally,  the  following  software  package 
was  accepted  as  part  of  the  system: 

1.  Operating  System . 0S/32HT, 

2.  compiler . Cobol,  and 

3.  anilities . Telecommunications  ITAM  32. 

Data  Entry  HR  AC 

On  30  September  197  7,  the  Automatic  Data  Processincr 
Selection  Office  (ADPSO)  issued  a  delivery  order  contract, 
N66 032-76-  D-0  004 ,  for  the  acquisition  of  the  initial  hard¬ 
ware  requirements  of  the  APADE  II  system.  This  was 
performed  in  accordance  with  SECNAVINST  5236.  1A, 
Specification,  Selection  and  Acquisition  of  Automatic  Data 
Processing  Equipment.  It  was  planned  that  Interdata  proces¬ 
sors  and  oeriphial  equipment  would  be  delivered,  installed, 
and  accepted  at  the  rate  of  two  a  month  until  all  deliveries 
were  completed.  The  first  deliveries  started  to  arrive  at 
the  prototype  and  development  sites  by  December  1977. 


4 .  System  Development 
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On  16  August  1977,  in  a  letter  to  NAVStJP  049,  the 
Commanding  Officer  of  FSSO  voiced  the  concern  that,  "we  may 
be  moving  too  quickly  and  have  not  yet  thought  out  all 
aspects  of  the  APADE  project. "  One  specific  area  of  concern 
dealt  with  the  application  software  development.  There  was 
no  indication  of  who  would  accomplish  this  effort,  i. e. , 
PESO  or  a  contractor.  FHSO's  CO  advocated  contracting  out 
this  effort  due  to  the  lack  of  personnel  at  FMSO  with  the 
needed  experience  in  this  area.  Additionally,  he  considered 
that  application  software  development  would  take  longer  than 
the  NAVSUP  Command  plan  indicated.  He  stated  that,  "FHSO*s 
personnel  estimated  a  minimum  of  six  to  eight  months  after 
award  of  a  contract  for  delivery  of  a  first  module,  with 
full  development  taking  as  long  as  fifteen  months. 

The  CO  also  addressed  the  issue  that  no  formal  plan 
had  been  formulated  for  maintenance  of  the  system.  He 
emphasized  that  FNSO  would  be  the  best  choice,  but  specific 
resource  requirements  would  be  difficult  to  estimate  until 
the  application  software  was  designed.  In  addition,  he 
expressed  concern  that  no  formal  plan  presently  existed  for 
incorporating  any  on-line  interfaces  via  APADE  II. 

a.  Request  for  ADP  Services 

On  2  September  1977,  F!1SO  submitted  a  request 
for  ADP  services  to  the  General  Service  Administration  (GS A) 
via  GS  A  form  2068  ,  in  accordance  with  the  Federal 
Procurement  Regulations.  (  As  described  in  Chapter  Three, 
this  is  a  request  for  a  Delegation  of  Procurement  Authority, 
DPA)  The  request  provided  the  description  of  the  minicom¬ 
puter  system  that  had  been  agreed  upon  earlier  as  the 
minimum  equipment  configuration.  If  described  the  software 
package  being  procured  from  Interdata  and  proposed  the 
following  personnel  requirements: 
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1.  One  Team  Leader  Analyst, 

2.  Two  Computer  Systems  Analysts,  and 

3.  Four  Programmers. 

The  description  of  requested  services  indicated 
that  FHSO  would  provide  systems  specifications  from  which  a 
computer  system  was  to  be  designed  and  programs  written  in 
addition  to  testing,  debugging,  and  implementation  of  the 
system  at  the  first  site.  Additionally,  the  request 
provided  the  following  system  definition: 

The  APADE  II  System  shall  consist  of  a  standard  set  of 
equipment  and  software  components  configured  according 
to  the  performance  characteristics  required  by  each  of 
the  thirteen  (13)  sites  receiving  the  system.  The  stan¬ 
dard  equipment  and  software  set  shall  be  adaptable  for 
each  of  the  user  sites  according  to  the  definitions  and 
constraints  specified  herein. 

Further,  the  request  stipulated  that  APADE  II  would  support 
five  system  functions.  These  functions  were: 

1.  Procurement  Tracking, 

2.  Procurement  Record /Hi story, 

3.  Document  Generation, 

a.  Management  Information,  and 
5.  Telecommunications  Interface. 

Each  of  thes  system  requirements  are  summarized  in  Appendix 
C. 

On  6  September  1977,  GSA  notified  FMSO  that  it 
chose  not  to  issue  a  Delagation  of  Procurement  Authority.  It 
further  directed  that  the  work  would  be  performed  through 
the  use  of  an  existing  ADP  Service  loatract,  negotiated  by 
GSA,  Atlanta,  for  the  Interagency  Data  System  Facility 
(IDSF)  located  in  Huntsville,  Alabama. 

Since  1967,  3SA  has  maintained  the  IDSF  at 
Huntsville  and  administered  an  ADP  service  contract  with  a 
commercial  vendor.  The  major  function  of  this  facility  is 
to  provide  a  convenient  and  economical  source  of  systems 
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analysis  and  programming  talent  for  snail  dollar  value  (less 
than  $250,000)  requirements  of  Federal  agencies,  especially 
when  a  fast  start-up  is  desired. 

IDS F  functions  as  the  project  monitor.  In 
general,  they  provide  spare,  supplies,  telephone,  etc.,  to 
the  contractor,  forward  contractor  estimates  in  response  to 
request  for  task  order  amendments,  and  verify  contractor 
charges  against  the  project  task  orders.  However,  all 
Contracting  officer  responsibilities  are  retained  by  the  GSA 
regional  office  in  Atlanta. 

It  should  be  understood,  that  these  ADP  tech¬ 
nical  support  service  contracts  are  nothing  more  than  a  time 
and  material,  requirement  type  contract.  GSA-IDSF  orders 
labor  hours  at  a  specified  rate  and  material  at  cost.  This 
type  of  contract  requires  constant  monitoring  to  ensur® 
efficient  and  effective  use  of  government  resources. 

On  8  September  1977,  FMSO  requested  an  estimate 
of  time  and  cost  to  perform  the  services  outlined  on  the  GSA 
Form  2068  from  IDSF  Huntsville.  The  initial  GSA  estimate 
for  the  total  APADE  II  application  software  was  approxi¬ 
mately  $248,000  with  an  estimated  completion  date  of  April 
1979. 

b.  Memorandum  of  Under standing 

On  21  October  1977,  a  Memorandum  of 
Understanding  (MOO)  between  GSA-IDSF  and  FMSO  was  signed. 
The  general  purpose  of  the  MOD  was  to  establish  a  working 
agreement  through  which  GSA-IDSF  would  provide  ADP  technical 
support  services  on  a  reimbursable  basis  to  FMSO. 
Specifically,  GSA-IDSF  would  issue  task  orders  to  the 
support  contractor  based  an  the  work  requirements  and  speci¬ 
fications  submitted  by  PMS0.  Ho  single  task  order  issued  by 
GSA-IDSF  could  exceed  $253,000  for  total  support  cost.  All 


alterations  and  modifications  of  amendments  required  prior 
approval  by  FMSO.  The  performance  period  would  be  governed 
by  the  requirements  and  specifications  for  each  individual 
task  as  prescribed  by  FMSO. 

The  initial  task  orders  to  be  accomplished  were: 

1.  System  Specifications, 

2.  Data  Base  Requirements  Document, 

3.  Test  Plan, 

4.  Program  Specifications, 

5.  Program  Coding  and  Testing, 

6.  System  Integration, 

7.  Acceptance  Testing, 

8.  User  Manual, 

9.  Training,  and 

10.  Quality  Assurance  Program. 

A  summarization  of  each  task  is  provided  in  Appendix  D. 

It  should  be  noted  at  this  time  that  Task  One, 
System  Specifications,  was  to  be  based  upon  the  APADE  II 
Functional  Description  being  provided  by  FMSO. 

As  a  result  of  the  MOO,  a  prc-Ject  order  was 
issued  on  21  October  1977  to  GSA-IDSF  for  APADE  II  applica¬ 
tion  software  development.  Funds  amounting  to  $198,000  were 
provided  for  the  initial  ten  tasks  in  addition  to  an  evalua¬ 
tion  of  possible  use  of  a  file  management  ,  inquiry  and 
retrival  system  and  telecommunications  package,  TAPS 
(Terminal  Application  Processing  System)  for  use  in  APADE 

II.  System  predesign  and  software  evaluation  was  initiated 
under  task  orders  H587  and  H538  by  Potomac  Research, 
Inc.(PRI),  the  GSA-IDSF  support  contractor  in  December  1977. 
Development  hardware  was  delivered  to  the  development 
contractor,  PRI,by  20  January  1973.  The  hardware  was 
finally  installed,  tested,  and  accepted  by  PRI  on  31  March 


c.  Modular  system  Concept 
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As  early  as  July  1977,  modular  system  develop¬ 
ment  and  installation  was  planned  for  the  APADE  II  project. 
This  was  first  indicated  in  the  15  July  1977  preliminary 
system  design  specifications  published  by  FSSO.  The  modules 
were: 

1.  Module  I  .  Purchase  requisition  tracking, 

2.  Module  II  .....  Automated  document  preparation, 

3.  Module  III  ....  Management  Information  Reports,  and 

4.  Module  I?  .  Interface  with  other  systems. 

On  15  December  1977,  FMSD  published  the  APADE  II 
Management  Plan  which  was  prepared  by  Computer  Data  Systems, 
Inc.  The  purpose  of  the  plan  was  to  provide  an  outline  of 
required  management  actions  and  related  milestones.  It 
would  be  used  to  plan  and  execute  APADE  II  development, 
evaluation,  operational  implementation  and  maintenance. 
This  plan  also  referenced  APADE  II  modules  in  describing  the 
implementation  plan.  Although  modular  system  development 
appeared  in  both  of  these  documents,  no  reference  to  this 
fact  was  made  in  the  ADS  development  plan. 

In  May  1978,  the  Functional  Description  (FD)  was 
published  by  FMSO  after  having  been  completed  under  contract 
with  Computer  Data  Systems,  Inc.  The  FD  indicated  that  the 
system  would  be  implemented  in  the  field  one  module  at  a 
time.  It  furnished  the  following  target  dates  for 
implementation: 

1.  Module  I  .  August  1978, 

2.  Module  II .  November  1973, 

3.  Module  III  ....  February  1979,  and 

4.  Module  17  .  April  1979. 


a.  Module  I  Development 

The  task  order  (H585)  under  which  Potomac 
Research,  Inc.  (PHI)  commenced  the  developement  of  APADE  II 
was  initiated  in  February  1978.  As  previously  mentioned, 
the  task  required  the  contractor  to  prepare  system  specifi¬ 
cations  and  succeeding  deliverables  from  the  government 
provided  FD  and  DRD.  However,  these  items  were  not 
completed  by  Computer  Data  Systems,  Inc.  (CDSI)  until  15  May 
1978.  Therfore,  PRI's  effort  during  the  interim  was  based 
on  preliminary  versions  of  these  documents  in  addition  to 
direct  meetings  between  FHSO,  PRI,  and  CDSI  personnel. 

For  the  next  four  months,  from  February  until 
May  there  were  no  indirations  of  any  problems  with  the 
development  effort.  PRI  was  reporting  their  work  perfor¬ 
mance  every  two  weeks  by  submitting  task  order  activity 
reports  to  FMSO.  Additionally,  two  meetings  were  conducted 
between  the  contractor  and  FMSD  personnel  during  that 
period.  On  19  May  1978  PRI  indicated  that  they  were  experi¬ 
encing  difficulty  with  the  TAPS  package  and  the  Interdate  OS 
32  editor.  This  was  also  the  first  time  that  they  reported 
the  use  of  over-time.  As  of  14  July  1978,  they  had  not  yet 
completed  system  testing  of  Module  I.  Implementation  on 
Module  I  at  the  orototype  site  was  scheduled  to  commence  on 
17  July  1978. 

e.  Prototype  Testing 

NSC  Oakland  was  selected  as  the  prototype  test 
site  because  they  were  experiencing  sever  problems  in  the 
area  of  small  purchases.  During  that  year,  approximately  58 
percent  of  the  procurement  department's  personnel  were 
devoted  to  small  purchases.  They  were  receiving  from  2509 
to  3000  purchase  requests  per  weak  for  non-standard,  low 
dollar-value  (less  than  51  0,000)  items.  This  eventually 


resulted  in  a  weekly  output  of  1200  to  1500  award  documents. 
Because  of  the  manual  methods  employed  to  collect  data  on 
wcrk  load  distribution,  buyer  production,  and  requisition 
status,  management  control  of  the  procurement  process 
involving  this  many  requisitions  was  greatly  reduced, 
approximately  600  customer  inquiries  were  being  received 
weekly  which  proved  to  be  a  costly  and  time-consuming  manual 
task  fBef.  15;  p.9]. 

Since  Module  I  was  specifically  designed  to 
provide  the  management  data  needed  to  control  and  simplify 
small  purchase  processing,  NSC  Oakland  would  provide  an 
excellent  test  of  the  module.  In  addition,  NSC  Oakland  had 
budgeted  for  the  personnel  decrease  associated  with  the 
productivity  increase  to  be  accrued  with  APADE  II  for  both 
FT  79  and  FT  80. 

Implementation  of  Module  I  was  originally  sche¬ 
duled  from  17  July  thru  28  July  1978.  Although  implementa¬ 
tion  was  initiated  on  17  July  1978,  it  was  not  fully 
stabilized  until  February  1979.  This  was  due  to  several 
problems.  The  implementation  suffered  a  series  of  software 
and  hardware  problems  which  required  several  changes  to  the 
initial  software  design  in  addition  to  requiring  more  hard¬ 
ware.  FBSO  reported  that  the  software  had  to  undergo  exces¬ 
sive  debugging  during  the  implementation  effort.  This 
entailed  many  long  hours  of  reprogramming  by  contractor 
personnel.  Another  problem  encountered  was  that  the 
GSA-IDS  F  ADP  technical  support  contract  expired  on  30 
September  1978.  On  12  August  1978,  FMSO  was  informed  the 
follow-on  contract  had  been  awarded  to  Computer  Sciences 
Corporation  (CSC)  and  would  become  effective  1  October  1978. 
Although  the  majority  of  personnel  and  especially  the 
project  leader,  were  hired  by  the  new  contractor,  it  caused 
disruption  to  the  implementation  process. 


On  2  January  1979,  the  contractor's  project 
leader  (the  only  project  leader  since  the  project  initia¬ 
tion)  abruptly  left  the  contractor.  Only  at  that  time  was 
it  discovered  that  no  substantiating  documentation  for  any 
modules  existed.  The  project  leader  had  mentally  controlled 
all  development  efforts  and  the  application  software  without 
providing  any  written  documentation  of  his  undertakings.  It 
required  the  following  two  months  to  recover  lost  progress 
and  rebuild  system  documentation.  In  addition  to  the  docu¬ 
mentation,  FMSO  considered  that  adequate  test  plans  and 
procedures  had  not  been  established  nor  used.  It  expressed 
that  the  majority  of  the  problems  encountered  were  discov¬ 
ered  on  site,  impacting  on  the  implementation  process. 

Overall,  the  results  of  the  problems  encountered 
were  that  prototype  testing  became  nonexistent  and  implemen¬ 
tation  by  trial  and  error  was  the  game  plan.  By  20  February 
1979,  Module  I  of  APADE  II  had  been  implemented  at  NSC, 
Oakland.  Development  on  the  remaining  modules  continued 
under  the  MOO  with  GSA-IDSF. 

f.  Second  Test  Site 

On  12  February  1979,  the  Officer  In  Charge  (OIC) 
of  NHCO  Washington,  D.C.  requested  that  Module  I  of  Apade  II 
be  implemented  at  his  activity.  He  stated  that  NRCO 
Washington  had  an  urgent  need  for  an  improved  requisition 
tracking  system.  The  OIC  considered  that  since  the  hardware 
for  APADE  II  had  been  received  and  installed  at  his 
activity,  implementation  of  Module  I  was  a  viable 
alternative  [  Hef .  16:  p.  1]. 

The  systems  test  plan  required  that  FMSO  recom¬ 
mend  to  NAVSOP  044  when  a  module  was  ready  for  implementa¬ 
tion  at  the  other  proposed  sites.  Although  this  had  not 
been  done,  it  was  decided  in  March  that  the  results  at  NSC, 
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Oakland  were  sufficiently  encouraging  to  justify  a  second 
prototype  test  at  NRCO  Washington,  D.  C.  The  expansion  of 
Module  I  to  a  second  prototype  was  justified  by  emphasizing 
the  difference  in  procurement  volume  and  type  between  a  NSC 
and  a  NRCO.  The  NRCO  mainly  deals  in  a  low  volume,  high 
dollar  value  environment  whereas  the  NSC  deals  in  a  high 
volume,  low  dollar  value  environment  [Ref.  15:  p.11]. 

3y  the  end  of  April  1979,  CSC  had  generated  the 
Module  I  system  for  the  hardware  configuration  at  NRCO, 
Washington.  However,  no  specific  test  plan  stating  the 
goals  for  additional  testing  had  bean  developed.  Module  I 
was  implemented  at  NRCO  by  FMSO  personnel  in  May  1979 
without  assistance  of  contractor  personnel.  The  implementa¬ 
tion  effort  proved  more  sucessful  than  had  been  experienced 
at  Oakland.  This  was  mainly  due  to  the  availability  of  a 
stablized  software  system  and  the  volume  of  small  purchase 
actions  was  only  a  fraction  of  that  at  experienced  at 
Oakland.  In  addition,  no  increased  productivity  had  been 
forecasted  in  NRCO's  budget. 

g.  Contract  Administration 

After  the  severe  problems  encountered  during 
system  implementation  at  NSC,  Oakland,  FMSO  began  to  monitor 
both  GSA-IDSF  and  CSC  more  closely.  Although  the  MOO 
clearly  held  their  responsibility  as  tasking  and  funding  the 
project,  with  final  acceptance  authority,  FMSO  began  to 
become  more  involved  with  the  actual  contractor's  perfor¬ 
mance.  The  following  cor respondance  are  some  examples  of 
the  increased  interest  in  administration  of  the  contract  by 
FMSO. 

In  a  letter  dated  20  February  1977,  to  GSA-IDSF, 
the  FMSO  project  officer  for  APADE  II  requested  that: 
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.  CSC  review  ell  data  base,  system/subsy stem,  and 
program  specifications  of  Module  I  to  ensure  proper 
documentation, 

2.  CSC  provide  complete  documentation  for  Modules  II  and 
III  for  review  and  approval  before  any  programs  are 
written, 

3.  CSC  fully  staff  the  project  as  exhibited  in  their 
estimates,  and 

4.  CSC  exercise  greater  management  control  to  assure  all 
programs  conform  to  applicable  standards. 

In  March  1979,  CSC  notified  FMSO  that  the 
revised  estimate  for  completion  of  Module  II  was  August 
1979.  Since  that  estimate  would  put  the  project  a  total  of 
nine  months  behind  the  original  schedule,  FMSD  stated  that 
CSC  *  s  projected  completion  date  was  unacceptable.  It  a 
letter  to  GSA-IDSF  dated  14  March  1979,  FMSO's  CO  indicated 
that  although  over  2950  man-hours  have  been  reported  to 
develop  system/subsystem  specifications,  program  specifica¬ 
tions  and  other  documentation  on  Module  II  through  20 
January  1979,  little  progress  has  been  made  on  Module  II. 
He  requested  that  it  be  determined  what  had  to  be  done  to 
complete  Module  II  by  May  1 979.  In  addition,  as  a  result  of 
the  alleged  cost  to  date,  he  requested  GSA  audit  man-hours 
expended  versus  amount  of  accomplishment. 

The  response  letter  from  GSA-IDSF  cn  6  April 
1979,  indicated  that  CSC  was  not  required  to  report  hours 
expended  by  module  since  GSA  issued  the  project  as  a  single 
task  order.  Additionally,  the  estimated  completion  date  for 
Module  II  was  considered  reasonable  since  it  was  being 
developed  under  a  more  formalized  manner  than  Module  I. 
This  was  in  reference  to  the  approvals  tha*  were  required  by 
FMSO’s  letter  dated  20  February  1979. 
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It  was  approxim ately  this  same  time  period  that 
CSC  recommended  implementation  of  Module  II  in  two  phases:  A 
and  B.  Phase  A  would  contain  those  capabilities  and  files 
considered  a  priority  for  implementation  at  NSC,  Oakland. 
Phase  3  would  contain  the  remaining  files,  document 
processing  and  the  Integrated  Disbursing  and  Accounting 
(IDA)  interface.  Module  IIA  was  estimated  to  be  completed 
by  CSC  on  31  July  1979  with  implementation  at  Oakland  in 
August  1979. 

By  June  1979,  over  $300,000  had  been  spent  on 
the  application  software  development.  The  project  originally 
scheduled  for  an  April  1979  completion  date  had  no  firm 
completion  date  in  sight.  Because  of  development  and  imple¬ 
mentation  delays,  cost  overruns.  Naval  Audit  Service  recom¬ 
mendations  and  requirements  associated  with 
multiple-activity  standard  systems,  the  CNO  requested,  "that 
all  new  APADE  II  initiatives  be  held  in  abeyance  pending  a 
comprehensive  evaluation  of  the  project"  [Ref.  17:  p.  1]. 


7.  EVALUATION  AND  CONSTRAINTS 


A.  NAVDAC  EVALUATION  OF  APADE  II 

On  1 1  June  1979,  the  Chief  of  Naval  Operations  directed 
the  Naval  Data  Autonation  Command  (NAVDAC)  to  conduct  an 
evaluation  of  the  APADE  II  project.  He  further  requested 
that  the  evaluation  report  be  completed  no  later  than  12 
September  1979.  On  10  September  1979,  after  three  months  of 
thorough  evaluation,  NAVDAC  reported  their  findings  and 
recommendations  concerning  the  future  of  the  APADE  II 
project. 

1 .  NA VDAC  Findings 

NAVDAC* s  evaluation  report  indicated  several  areas 
in  which  serious  problems  had  developed  and  contributed  to 
the  projects  current  condition.  Those  areas  were: 

1.  Initial  project  planning, 

2.  Contractor, 

3.  Design, 

4.  Implementation,  and 

5.  Project  monitoring. 

The  following  discussion  is  a  summary  of  each  problem  area 
as  reported  by  the  NAVDAC  evaluation  team. 

a.  Initial  Project  Planning 

Upon  reviewing  the  initial  approval  process  and 
planning  of  the  development  process,  NAVDAC  considered  that 
the  projected  schedule  was  overly  optimistic  in  that  the 
magnitude  of  the  APADE  II  project  was  not  fully  understood. 
Additionally,  they  considered  the  system  design  concents 
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were  not  sufficiently  defined  to  justify  early  acquisition 
of  ADP  hardware. 

NAVDAC  also  indicated  that  a  major  failure  in 
the  early  stages  of  project  planning  was  in  defining  the 
requirements  of  the  application  software  development 
contractor.  Specifically  the  fact  that  the  contractor 
performed  software  development  before  the  Functional 
Description  (FD)  and  Data  Requiremnet  Document  (DRD)  were 
completed.  This  required  interpretation  of  the  functional 
requirements  by  the  development  contractor  and  subsequently 
resulted  in  disputes  as  to  the  consistency  between  developed 
program  and  functional  requirements.  In  addition,  the 
development  contractor  had  no  procurement  expertise  among 
his  personnel. 

Another  flaw  in  project  planning  was  a  lack  of 
detailed  test  plans  describing  what  tests  were  to  be 
conducted  and  by  whom.  The  Test  and  Implementation  Plan  did 
not  provide  for  test  data  recording,  reporting,  evaluating, 
or  approval  procedures. 

b.  Contractor 

NAVDAC  considered  the  change  of  the  GSA-IDSF  ADP 
Support  contract  from  PRI  to  CSC,  combined  with  the  abrupt 
departure  of  the  contractor's  project  leader,  significantly 
contributed  to  the  delay  in  software  develpoment.  However, 
they  indicated  that  coordination  with  and  control  of  the 
contractor  had  just  as  much  impact  an  inhibiting  the  devel¬ 
opment  process.  They  cited  the  failure  of  GS A  and  FMSO  to 
establish  intermediate  milestones  for  the  contractor  and  GS A 
to  monitor  progress  and  penalize  late  delivery  as  contri¬ 
buting  factors.  Also,  the  geographic  location  of  FMSO,  GS A, 
the  Development  Site,  and  the  Prototype  site  impeded  organi¬ 
zational  communications.  To  this  statement,  they  referenced 
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frequent  communications  between  CSC  and  FHSO  concerning 
interpretations  of  the  FD  and  system  requirements  without 
informing  GSA-IDSF.  This  led  to  verbal  changes,  additional 
labor  commitments,  contractor  claims,  and  disputes  over  the 
veracity  of  these  claims. 

c.  Design 

NAVDAC  stated  that  the  selection  of  TAPS  as  the 
file  management,  inquiry  and  retrieval  system  and  telecommu¬ 
nications  package  restricted  APADB  II  design.  They  indi¬ 
cated  that  designing  an  efficient  application  system  in  the 
TAPS  environment  required  an  extensive  knowledge  of  TAPS*s 
capabilities  and  limitations.  TAPS  was  a  relatively  new 
product  and  both  PHI  and  CSC  had  no  prior  experience  with 
this  package.  NAVDAC  reported  that  contractor  personnel 
possessed  only  a  limited  understanding  of  the  Interdata  7/32 
operating  package,  OS/32HT. 

The  system  design  did  not  allow  for  any  recovery 
capability.  The  only  back-up  capability  was  provided  by 
daily  copying  of  all  data  and  index  files  to  magnetic  tape. 

NAVDAC  also  considered  that  the  system  was  being 
developed  in  an  excessively  fragmented  fashion.  Although 
the  original  four  module  approach  was  acceptable,  fragmenta¬ 
tion  of  design  was  resulting  because  difficult  aspects  of 
certain  modules  were  being  transferal  to  later  module  devel¬ 
opment  or  formed  into  a  separate  module. 

NAVDAC  also  addressed  the  fact  that  no 
contractor  or  Navy  personnel  with  adequate  hardware  experi¬ 
ence,  in  general,  and  Interdata  hardware  experience,  in 
particlular,  were  included  in  the  project's  structure. 
There  were  no  means  to  ensure  efficient  utilization  of  the 
ADPE  selected. 


d.  Implementation 


One  of  the  major  problems  with  implementation 
was  the  decision  to  rush  Hodule  I  to  NSC  Oakland.  NA7DAC 
stated  that,  "  the  system  was  implemented  without  adequate 
prior  software  testing  to  satisfy  an  urgent  NSC  need  for  an 
automated  aid  to  their  small  purchasing  crisis.  Instead  of 
helping,  the  system  was  a  burden  to  NSC  management  and  a 
resource  drain  from  July  73  through  Pebruary  1979"  [Ref.  15: 
p.33  ]. 

e.  Project  Monitoring 

In  reference  to  project  monitoring,  NA7DAC  indi¬ 
cated  that  management  review  actions  were  not  initiated  when 
the  project  began  to  experience  problems  with  implementa¬ 
tion.  They  further  stated  that  the  ADS  development  plan  was 
not  updated  when  the  planning  estimates  proved  inaccurate. 
Additionally,  they  cited  the  December  1977  Management  Plan 
as  no  longer  current. 

They  also  indicated  that  although  the  current 
APADE  II  project  is  over  cost  and  behind  schedule,  no 
formalized  plan  had  been  developed  to  remedy  the  problems 
and  complete  the  project.  In  addition,  APADE  II  was  an 
unfunded  requirement  for  FY  80  and  out  years  in  the 
NAY SOPSYSCOM  ADP  budget  submission. 

Overall,  NA7DAC  considered  that  the  problems 
were  of  a  common  origin:  execution  before  or  without 
adequate  planning. 

2 •  Recommendtions 

The  following  discussion  is  a  summary  of  the  recom¬ 
mendations  from  NA7DAC  that  were  provided  to  the  CNO  on  10 
September  1979. 


First,  NAVDAC  caco amended  that  no  APADE  II  initia¬ 
tives  (development,  acquisition,  or  implementation)  be  taken 
prior  to  completing  the  following: 

1.  A  major  revision  to  the  APADE  II  ADS  development  plan, 

2.  Performance  analysis  and  benchmark  testing  of  hardware 
configuration  at  NSC  Oakland  to  accurately  identify 
the  hardware  requirements  that  have  only  been  esti¬ 
mated,  and 

3.  A  review  of  the  FD/DRD  prior  to  further  development 

with  a  Design  Review  Board  performing  a  final  review. 

It  was  also  recommended  that  APADE  II  PY  80  and  PY 

81  budgeting  requirements  be  prepare!  as  quickly  as  possible 
for  the  Chief  of  Naval  Material’s  (CHNA7MAT)  consideration. A 
third  recommendation  was  to  continue  with  software  develop¬ 
ment  and  documentation  through  the  completion  of  Module  IIA. 
In  addition,  it  was  recommended  to  implement  Module  IIA  at 
the  current  prototype  sites,  and  at  limited  additional 
NAVSUPS YSCOM  sites  following  CHNA7MAP  approval  of  prototype 
test  results. 

NAVDAC's  fourth  recommendation  stated  that  ADP 
Readiness  Reviews  at  the  activities  not  reviewed  should  be 
done  and  documented  for  CHN  AVMAT  aporoval.  Finally,  if  the 

CNO  should  ultimately  approve  continuation  of  APADE  II 

development,  the  following  additional  recommendations  were 
submitted. 

1.  Formalize  *est  and  acceptance  procedures, 

2.  Premature  implementation  should  be  avoided, 

3.  If  software  development  is  continued  under  contract, 
the  contract or /FMSD  relationship  should  be  more 
formalized, 

4.  Provide  basic  and  advanced  training  in  capabilities 
and  limitations  of  TAPS  to  development  programmer/ana¬ 
lysts,  and 
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B.  CNO  CONSTRAINTS 

Subsequently,  the  CNO  reviewed  the  NAVDAC  report  and 
provided  reconaendat ions  in  his  letter  dated  1  November 
1979.  This  letter  placed  a  number  of  constraints  upon  the 
APADE  II,  specifically  that : 

1.  Implementation  of  Module  IIA  would  be  restricted  to 
the  two  prototype  sites,  NSC  Oakland  and  NRCO 
Washington,  D.C.  and 

2.  There  would  be  no  further  development,  beyond  module 
IIA. 

These  two  constraints  would  remain  in  effect  until  the 
following  conditions  were  satisfied: 

1.  Submission  and  approval  of  a  aew  ADS  plan  including  a 
cost/benefit  analysis  contrasting  in-house  vs 
contractor  development, 

2.  Completion  of  a  hardware  sufficiency  analysis  to 
determine  hardware  type  and  size  requirements  for  each 
site, 

3.  Update  of  the  APADE  1 1  PD  and  DRD  following  a  detailed 
review  of  these  documents,  and 

4.  Preparation  and  submission  of  APADE  II  PI  80  and  PI  81 
budgetary  requirements  for  CHNAVMAT's  consideration. 


C.  SUMMARY 

The  current  redesign  effort  is  applying  the  lessons 
learned  from  APADE  I  and  II  to  a  Life  Cycle  Management 
approach  developing  a  totally  integrated  and  exportable 
automated  procurement  system.  The  modular  development  and 
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design  approach  has  been  discontinued, 
requirements  are  presently  being  paralleled  with  the  devel¬ 
opment  cf  a  project  to  prcvide  new  hardware  to  the  major 
stock  points.  This  project  is  designated  as  stock  Point 
Logistics  Integrated  Communications  Environment  (SPLICE) . 
The  software  currently  used  will  be  utilized  only  if  it  is 
compa table  with  the  new  hardware  and  meets  the  redesign 
requirements  statement. 

The  new  APADE  system  will  apply  the  capabilities  of 
automated  data  processing,  automated  word  processing  and 
printing,  integrated  to  the  extent  permitted  by  current 
technology.  The  new  APADE  will  provide  a  standardized 
procurement  data  processing  system  designed  to  provide: 

1.  Document  control, 

2.  Management  and  Buyer  support  information, 

3.  Automated  document  and  report  preparation,  and 

U.  Interdependent  system  support. 

As  previously  mentioned,  the  redesign  effort  is  being 
performed  under  contract  with  Bocz-Allen.  Implementation  is 
currently  estimated  for  March  1983. 


VI.  CONCLUSIONS 


Por  approximately  the  last  35  years,  the  U.  S.  Navy  has 
been  involved  in  developing  and  implementing  automated  data 
system  (ADS)  within  their  organization.  However,  it  has 
only  been  within  the  past  few  years  that  the  Navy  has 
successfully  avoided  the  major  pitfalls  associated  with 
developing  and  implementing  these  systems. 

The  major  factors  contributing  to  improved  management 
decisions  within  ADS  development  and  implementation  are 
historical  knowledge,  improved  technology,  and  increased 
education  in  this  rapid  expanding  field.  This  has  lead  to  a 
change  of  philosophies  among  the  personnel  tasked  with 
development  and  implementation  of  ADS,  in  addition  to 
improved  regulations  that  provide  clear  and  concise 
guidelines  for  these  personnel. 

One  article  which  provides  an  excellent  view  of  the  ADS 
development  process  within  the  Navy  was  published  in  1976  by 
Rear  Admiral  Prank  S.  Haak.  The  article  entitled, 
"Brainware  versus  Hardware n  presented  six  major  sequential 
phases  for  the  development  of  ADS  within  the  O.S.  Navy. 
They  were: 

1 .  Planning, 

2.  Technical  Development, 

3.  Hardware  Acquisition, 

h.  Programming, 

5.  Installation,  and 

6.  Haintenance. 

The  planning  phase  is  initiated  by  identifying  the  ADS 
in  terms  of  content,  scope,  boundaries  and  external  inter¬ 
faces.  This  will  lead  to  the  system's  performance 
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parameters  and  characteristics  coming  into  focus.  it  this 
time,  alternative  concepts,  designs  and  technical  approaches 
require  evaluation  to  determine  their  feasibility  and  rela¬ 
tive  effectiveness  in  satisfying  the  system  requirements. 
Technically  feasible  alternatives  should  then  be  subjected 
to  an  economic  analysis  for  selecting  the  optimum  system. 
The  planning  phase  should  provide  the  following  products: 

1.  &  well-defined  concept  for  an  automated  data  system 
capable  of  satisfying  the  particular  operational 
requirements  in  a  manner  consistent  with  established 
procedures, 

2.  An  evaluation  of  technically  feasible  alternatives  for 
implementing  the  ADS  concept  to  achieve  the  best 
possible  balance  between  capabilities  and  cost,  and 

3.  An  ADS  development  plan  which  identifies  time  sche¬ 
dules,  resources,  and  management  measures  necessary  to 
convert  the  concept  into  an  operational  capability  via 
the  selected  development  approach  [Hef.  18:  p.  14]. 

Admiral  Haak  indicated  that  short  cuts  in  this  phase 
would  probably  increase  the  risk  of  serious  performance  and 
economic  penalties  during  the  development,  operation,  and 
maint enanceof  the  ADS. 

Designing  the  ADS  initiates  the  technical  development 
phase.  It  requires  an  "explicit  definition,  organization, 
and  structuring  of  the  data  system  configuration  capable  of 
performing  all  processing  functions"  [Hef.  18:  p.15]. 

Following  the  designing  of  the  ADS,  formulation  of  detailed 
characteristics,  performance  requirements,  and  configuration 
criteria  for  a  compatible  computer  system  should  be 
completed.  Products  of  this  phase  should  include: 

1.  A  comprehensive  design  for  the  full-scale  ADS, 
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2.  A  functional  description  of  the  ADS  which  identifies 
the  manner  in  which  the  design  will  satisfy  the 
requirements  of  the  ADS  sponsor, 

3.  Detailed  specifications  for  all  data  bases,  files, 
application  programs  and  software  interfaces, 

4.  ADP  equipment  specifications  for  use  in  the  selection 
of  appropriate  general  purpose  computer  systems  for 
the  ADS,  and 

5.  A  revised  development  plan  reflecting  any  significant 

changes  and  refinements  in  the  milestones  schedules, 
resources,  requirements,  and  estimated  benefits 

presented  in  the  original  ADS  development  plan 

[Ref.  18:  p.16] 

Upon  determining  that  new  computer  hardware  is  required, 
proposals  are  then  solicited.  The  hardware  acquisition 

phase  should  result  in  a  particular  computer  configuration 
which  has  been  thoroughly  evaluated,  tested,  and  selected  on 
the  basis  of  both  performance  and  cost. 

The  programming  phase  is  divided  into  five  sequential 
tasks.  They  are: 

1.  Analyzing  specifications  to  identify  each  program  for 
structuring, 

2.  Coding  into  programming  language, 

3.  Preparing  test  data  and  organizing  test  routines  to 
detect  possible  errors, 

4.  Testing  each  unit,  and 

5.  Documenting  the  program.  [Ref.  18:  p.16-18.] 

After  completing  these  five  task,  system  integration  is 
performed  by  joining  individual  programs  into  organized 
modules.  The  analysis,  coding,  test  planning,  and  testing 
is  reported  and  recorded  as  integration  is  performed.  This 
phase  should  produce  the  following  products: 
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1.  Computer  programs  which  perform  all  functions  as 
specified  in  the  ADS  requirement  statement, 

2.  Documentation  for  proper  operation  and  maintenance  of 
the  ADS,  and 

3.  Complete  set  of  test  data.  [Hef.  18:  p.  18.] 

The  installation  phase  envolves  the  testing,  final 
acceptance  and  certification,  and  installation  of  the  ADS. 
The  testing  demonstrates  that  the  ADS  operates  in  an  effec¬ 
tive  and  reliable  manner  and  conforms  to  the  ADS  require¬ 
ments  and  objectives.  When  a  ADS  is  designed  for  more  than 
one  site,  the  test  will  be  designed  and  conducted  as  a 
prototype  evaluation. 

The  maintenance  phase  is  the  last  phase.  It  consists  of 
the  technical  support  required  to  eliminate  programming 
errors  and  provide  system  enhancements.  This  function  is 
usually  best  performed  by  the  activity  which  designed  and 
developed  the  system. 

Only  after  reviewing  Admiral  Haak's  article  does  a  full 
appreciation  for  the  scope  of  the  development  effort  formu¬ 
late.  By  comparing  the  APADE  II  project  and  the  development 
process  as  outlined  above,  the  underlying  reasons  for 
APADE's  delay  and  limited  success  become  more  apparent.  The 
majority  of  the  reasons  have  been  addressed  in  NAVDAC’s 
report  to  CNO.  However,  there  are  two  other  factors  which, 
in  this  researcher’s  opinion,  contributed  to  the  limited 
success  of  the  project. 

Although  all  activities  within  the  procurement  process 
are  governed  by  the  same  laws  and  regulations,  each  activity 
interprets  those  guidelines  in  a  slightly  different  manner. 
In  addition,  their  procedures  for  performing  the  procurement 


process  may  vary  according  to  prescribed  local  directives. 

Admiral  Haak  stated,  "Special  care  must  be  taken  to 
define  the  detailed  procedural  contest  of  a  proposed  ADS  and 


to  examine  its  interrelationships  with  the  functional 
systems  and  standard  operating  procedures  employed  within 
the  command.  If  the  proposed  procedures  deviate  from  some 
prescribed  standard  system,  it  is  prudent  to  propose  a 
change  to  the  standard  or  obtain  a  waiver  from  the  appro¬ 
priate  senior  before  proceeding.  If  the  procedures  cannot  be 
defined  in  explicit,  formal  detail,  they  simply  cannot  be 
automated  anyway"  [Hef.  18:  p.13]. 

Functionally,  the  procurement  process  could  be  described 
in  detail;  however,  the  local  operating  procedures  utilized 
by  the  various  NFCS  activities  altered  the  process  to  meet 
individual  command  requirements.  The  ADS  was  to  be  used  by 
all  designated  activities,  not  tailored  for  each  individual 
command.  Prior  to  the  development  of  the  ADS  for  APADE,  an 
extensive  planning  analysis  of  the  various  procedures 
employed  should  have  beea  undertaken.  Additionally,  the 
need  to  standardize  the  procedures  among  the  users  should 
have  been  evident.  An  initial  indication  of  this  occurred 
during  FMSO's  evaluation  of  automated  systems  used  by  NFCS 
activities.  None  of  these  systems  were  exportable  because 
they  were  not  comprehensive  and  designed  in  a  different 
manner  to  suit  just  one  activities  requirements.  This  fact 
should  have  clearly  indicated  that  there  was  no  standard 
system  among  the  activities. 

The  environmental  conditions  during  the  development 
effort  of  APADE  II  also  impacted  upon  the  process.  One 
reason  previously  addressed  was  the  changing  of  policies 
within  the  Navy's  ADP  program.  The  initial  development 
efforts  were  most  likely  acceptable  because,  similar  systems 
were  being  developed  in  the  same  manner.  However,  as  time 
progressed,  development  philosophies  began  to  be  refined  and 
a  new  method  of  ADS  development  evolved. 
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Another  reason  was  the  sense  of  urgency  for  the  automa¬ 
tion  of  the  procurement  process.  Faced  with  increasing 
procurement  actions  and  personnel  reductions  combined  with 
the  need  for  improved  procurement  information,  APADS 
appeared  to  provided  the  best  solution  to  overcome  these 
problems.  In  an  effort  to  provide  this  system  to  the  activ¬ 
ities,  management  decisions  and  planning  were  unrealisti¬ 
cally  expedited. 

Although  the  APADE  II  project  is  a  good  example  of  how 
not  to  develop  and  implement  an  ADS,  it  provides  valuable 
insight  for  managers  to  apply  in  developing  and  implementing 
future  automated  data  systems.  As  long  as  the  same  mistakes 
are  not  continually  repeated,  progress  will  be  made  in  the 
effort  to  automate  the  procurement  process. 


APPENDIX  A 


PaOCO£EM3NT  JNPOT,  30TPUT,  AND  REPORT  DOCUMENTS 

The  following  are  examples  of  input  documents  received 
by  the  NSC's  and  NRCC's: 

1.  Standard  Form  129,  "Bidders  Mailing  List  Application", 

2.  DD  Fora  633,  "Contracting  Pricing  Proposal", 

3.  DD  Form  1149,  "Requisition  and  Invoice/Shipping 
Document" , 

4.  DD  Form  1348,  "Single  Line  Item  Requisition  Document 
(Manual) " , 

5.  DD  1348M,  "Single  Line  Item  Requisition  Document 
(Mechanized)  ", 

6.  DD  Form  1348-1,  "  Single  Line  Item  Release/Receipt 

Document", 

7.  DD  Form  1348-b,  "Non-NSN  Requisition  (Manual)", 

8.  DD  Form  1594,  "Contract  Completion  Statement", 

9.  NAVCOMPT  Form  227  6,  "Request  for  Contractual 
Procurement", 

10.  NAVSOP  Form  1153,  "Request  for  Purchase  Action", 

11.  NAVSEA  Form  4700/2,  "Job  Material  List  (JMI)  ", 

12.  Shipment/Performance  Notification, 

13.  Notification  of  Payment, 

14.  Letter/Message  Purchase  Request, 

15.  Material  Request,  and 

16.  Automated  Bid  Sheets. 

The  following  is  a  list  of  some  of  the  procurement 
output  documents  distributed  by  NSCs  and  NRCCs: 

1.  Standard  Form  18,  "  Request  for  Quotations", 

2.  Standard  Form  26.  "Award/Contract", 
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3.  Standard  Form  30,  "Amendment  of 

Solicitations/Modification  of  Contracts", 

4.  Standard  Form  33,  "Solicitation,  Offer,  and  Award", 

5.  Standard  Porm  36,  "Continuation  Sheet", 

6.  Standard  Form  98,  "Notice  of  Intention  to  Make  a 
Service  Contract  and  Response  to  Notice”, 

7.  Standard  Form  99  Notice  of  Award  of  Cotract", 

3.  Standard  Form  1034,  "Public  Voucher  for  Purchases  and 
Services  Other  than  Personal", 

9.  DD  Form  1155,  "Order  for  SuppLies  or  Services/Reguest 
for  Quotations", 

10.  DD  Form  1384,  "Transportation  Control  and  Movement 
Document" , 

11.  DD  Form  1499,  "Report  of  Individual  Contract  Profit 
Plan", 

12.  DD  Form  1594,  "Contract  Completion  Statement", 

13.  DD  Form  1501,  "Abstract  of  Bids", 

14.  DD  Form  1524,  "Pre-Award  Survey  of  Offerors", 

15.  DD  Form  1707,  "Information  to  Offerors  of  Quoters", 

16.  NAVMAT  Form  4380/1,  "Labor  Surplus/Small  Business  Set 
Aside”, 

17.  Assignment  to  Contract  Administration  Activity, 

18.  Best  and  Final  Notification, 

19.  Bidder’s  Lists, 

20.  Bid  Verification,  Blanket  Purchase  Agreement 
(BPA) /Basic  Ordering  Agreement  (30A)  , 

21.  Business  Clearances  (Pre  and  Post), 

22.  Buyers'  Draft  Sheet, 

23.  Navy  Chief  of  Information  (CNINF0)  New  Release, 

24.  Commerce  Business  Daily  Synopsis  (before  and  after 
award)  , 

25.  Contract  Review  Board  Approval  Request, 

26.  Cure  Notice, 
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27.  DSF  (Determination  and  Findings)  , 

28.  Letter  Contract, 

29.  Son-Personal  Services  Questionnaire, 

30.  Non-Standard  Procurement  Notification, 

31.  Notice  of  Intent  to  Exercise  Option, 

32.  Notice  of  Termination, 

33.  Notice  to  Unseccessful  Offerors, 

34.  RAN  (Request  for  Authority  to  Negotiate), 

3  5.  Request  for  Audit, 

36.  Request  for  COTR/Ordering  Officer  Assignment, 

37.  Request  for  EEO  Compliance  check, 

38.  Request  for  Latest  Collective  Bargaining  Agreement, 

39.  Request  for  Non-Personal  Services  Statement, 

40.  Request  for  Ordering  Data, 

41.  Request  fo  SBA  for  Certificate  of  Competency, 

4  2.  Request  for  Sole  Source  Statement, 

43.  Request  for  statement  of  Urgency, 

44.  Request  for  Technical  Evaluation  Factors, 

4  5.  Show  Cause  Letter, 

4  6.  Stop  Work  Order,  and 

47.  UADPS_SP  Update  Transactions. 

The  NSCs  and  NRCCs  produce  ,  among  others,  the  following 
reports: 

1.  DD  Form  350,  ’’Individual  Procurement  Action  Report", 

2.  DD  Form  1057,  "Monthly  Procurement  Summary  by 
Purchasing  Ofice", 

3.  NAV"UP  Form  80,  "Purchase  Statistics", 

4.  Small  and  Disadvantaged  Business  Utilization  Report, 

5.  Monthly  Procurement  Administrative  Leadtiie  Report, 

5.  Letter  Contract /Other  Unpriced  Order  Report, 

7.  Uniform  Management  Report,  and 

8.  Monthly  Procurement  Backlog  Reoort. 
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APPENDIX  B 

COMMAND  PLAN  #338 


CONWANO  PLAN  APACE 
REVISED  April  1977 


1.  Organizational  Element; 

Deputy  Commander,  Procurement  Management. 

2.  Coal  Statement: 

To  provide  an  automated  procurement  management  system  to  major 
field  procurement  activities. 

*  •  ....  . . . • 

3.  Naval  Supply  Systems  Command  Objectives  Supported: 

Specific  Objectives  SO  (Source  Data  Automation),  3S  (Improved 
Supply  Performance) ,  and  92  (Automation  of  Procurement) . 

4.  Statement  of  Significance; 

The  APADE  project  will  provide  an  automated  procurement  management 
system  to  11  NAVSUP  procurement  activities  and  18  other  major  field 
purchasing  activities  with  capabilities  for  PR/requisition  tracking, 
automated  document  preparation,  and  management  information  reports. 

The  system  will  also  have  source  data  automation  capabilities  to 
enable  transfer  of  pertinent  procurement  data  to  interfacing,  depen¬ 
dent  financial  and  supply  data  systems  without  manual  intervention. 
Overall  effect  will  be  to  improve  field  procurement  function,  reduce 
cost  of  procurement  operation,  reduce  procurement  administrative 
leadtime,  provide  more  responsive  support  to  NFPS  customers.  * 

5. ’  Means  to  Measure  Progress  Toward  Goal  Accomplishment; 

The  NAVSUP  Command  Plan  reporting  system  will  be  utilized  to 
monitor  accomplishment  of  this  goal. 

6.  Tasks  Which  Contribute  Toward  Goal  Accomplishment: 

a.  Finalize  Systems  Policy  Concept- 

b.  Develop  Systems  Design  Specification. 

c.  Identify  Hardware  Requirements  and  Software  Requirements. 

d.  Develop  requirements  documentation. 

e.  Obtain  Hardware  requisition  approval. 

f.  Procure  Hardware/Software. 


Enclosure  (1) 
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g.  Test  and  Implement  at  NSC  Oakland. 

h.  Implement  at  remaining  NAVSUP  commanded  activities. 

i.  Implement  at  non-NAVSUP  commanded  activities  (18  sites}. 

7.  Description  of  Activity  Goals: 

FHSO  -  Provide  analysis,  contracting,  implementation  and  maintenance 
support. 

S.  Availability  of  Authority  Within  Organizational  Element  to 


.  Accomplis 

.  For  NAVSUP  commanded  activities  no  additional  authority  is  required. 
'For  non-NAVSUP  commanded  activities  authorization  will  be  coordinated 
with  NAVMAT  and  parent  SYSCOH's. 

~  9.  Estimated  Time  for  Accomplishments:  '  ~  -  ™ 

NAVSUP  commanded  activities  -  18  months  after  approval. 

Non-NAVSUP  commanded  activities  -  36  months  after  approval - 

10.  Relationships  Between  This  and  Other  Goals  Submitted  b 
Organizational  Elements: 


11.  Resources: 


a.  SUP  02  -  2M/Y. 

SUP  04  -  2M/Y. 

b.  FMS096  -  4M/Y. 
maintenance  1M/Y  continuing. 

c.  $1.3M  OPN  for  11  NAVSUP  activities  available  FY  77. 

d.  $1.8M  OPN  for  18  non-NAVSUP  (POM  79). 

e.  JSO  -  7SK  08MN  $  for  contractor  support. 
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Ct&MAND  PLAN:  338  REVISED  APR  1977 


HOGRAM  PLAN  — NAVSUP  FOAM  26 U  (7  66) 


APPENDIX  C 


APADE  II  SYSTEM  FUNCTIONAL  REQUIREMENTS 

Procurement  Tracking 

The  APADE  II  system  shall  provide  on-line  request  and 
retrieval  functions  to  support  the  procurement  tracking 
process.  These  functions  shall  provide  interactive  terminal 
access  to  the  Purchase  Master  Pile  disk  records  giving 
information  regarding  the  general  purchase  request  status. 

Procurement  Record/History 

The  APADE  II  system  shall  support  the  functions  of 
procurement  records  and  history  by  providing  a  Purchase 
Master  File  on  disk  containing  a  record  for  each  active 
procurement  in  process.  A  Purchase  Master  File  record  shall 
be  initiated  each  time  the  Procurement  Branch  begins  a 
procurement  activity.  As  the  activity  moves  through  the 
various  stages  of  procurement,  the  corresponding  records  of 
the  Purchase  Master  Pile  shall  be  updated  via  local  or 
remote  inreractive  CRT  and  batch  modes. 

Document  Generation 

The  document  generation  function  shall  imclude  a 
combination  of  on-line  interactive  CRT  data  entry  and 
periodic  batch  operations.  Specific  Navy  and  other  military 
regulations  shall  be  entered  via  this  function  and  stored  on 
disk  by  the  system.  This  information  shall  then  be 
available  for  retrieval  and  editing  along  with  the  entry  of 
specific  text  for  the  preparation  of  the  various  formal 
procurement  documents. 
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Management  Information 

The  management  information  function  shall  provide  a 
combination  of  interactive  on-line  data  entry  and  batch 
oriented  operations.  The  procurement  office  management 
requires  the  ability  to  request  information/data  from  the 
APAD2II  System  on  various  aspects  of  the  procurement  office 
processing  (auditing)  cycle  plus  the  ability  to  generate 
periodic  batch  reports.  The  reports  may  then  be  utilized  by 
internal  procurement  office  personnel  and  external  Navy 
commands  for  purposes  of  reviewing  each  procurement  office's 
progress,  outstanding  purchase  requests,  situations,  and 
expenditure  data. 

Telecommun ication  Int erf ace 

The  telecommunication  interface  function  shall  provide 
the  ability  for  the  APADE  II  System  to  communicate  via 
common  carrier  (telephone  facilities!  services  with  external 
D.S.  Navy  Financial  and  Supply  computerized  Data  Systems. 
This  interface  shall  be  utilized  by  the  Navy  Procurement 
Office  for  purposes  of  exchanging  (input  or  output)  APADE  II 
data/information  with  certain  other  Navy  facilities. 


AP PEND IX  D 

A PAPE  H  INITIAL  TASK  ORDERS  TO  GSA-IDSF 

Task  One  -  Syst  en  Specif  ica  tions  (SS> 

The  System  Specification  is  written  to  provide  detailed 
definition  of  the  system  functions,  to  provide  ongoing 
analysis,  and  to  define  in  detail  the  facilities  to  be 
utilized  to  accomplish  the  interfaces.  All  programs 
necessary  are  described.  The  SS  shall  be  written  according 
to  NAVSUP  PUB's  506,  507,  and  508  and  as  such  will  be  based 
on  the  APADE  II  Functional  Description  (FD)  .  The  SS  will  be 
reviewed  by  FMSO  for  consistency  with  the  ?D.  The  approved 
SS  will  be  the  basis  for  further  system  development.  If 
modifications  are  found  to  be  appropriate  to  the  SS,  all 
such  changes  shall  be  made  by  the  development  contractor 
only  on  written  approval  by  NAFSUP. 

Task  Two  -  Data  Base  Specifications  (DS) 

The  DS  describes  the  storage  allocation  and  data  base 
organization  that  provides  the  basic  design  data  necessary 
for  construction  of  system  files,  tables,  dictionaries  and 
directories.  The  DS  shall  be  written  according  to  NAVSUP 
PUB's  506,  507  and  508  and  as  such  shall  be  based  on  the  FD, 
RD,  SS,  and  PS.  The  DS  will  be  subject  to  FMSO  approval  and 
once  approved  all  changes  shall  be  reviewed  and  approved  by 
FMSO. 

Task  Three  -  Jest  Elan 

Test  plans  will  be  written  for  two  levels  of  formal 
testing.  The  upper  level  of  test  plan  shall  be  based  on  the 
FD  objectives  and  requirements  while  the  lower  level  shall 
be  based  or.  the  SS  and  its  identified  requirements.  The 


t«ss»*  plan  shall  be  reviewed  and  approved  by  FMSO.  The 
Functional  Test  Plan  on  upper  level  test  plan  shall  test  the 
system  from  the  user  viewpoint  and  will  demonstrate  system 
inputs  and  outputs  at  the  user  level.  The  program  test  plan 
shall  test  the  system  from  the  maiatainer's  viewpoint  and 
shall  demonstrate  consistency  between  delivered 
documentation  and  the  system  code  that  is  used. 

Task  Four  z  Pro gran  Specif i cation  (PS) 

The  PS  describes  the  program  design  in  sufficient  detail 
to  permit  program  production  by  the  coder.  References  for 
the  PS  are  the  FD  and  the  SS.  The  PS  shall  be  written 
according  to  NAVSOP  POB' s  5  06,  507  and  508.  The  PS  shall  be 
submitted  to  FMSO  for  review  of  consistency  with  the  SS  and 
FD.  Changes  which  do  not  effect  those  higher  level 
documents  may  be  made  by  the  development  contractor  at  his 
discretion  but  must  be  submitted  for  review  by  FMSO. 

Task  Four  -  fiioasa®  Sali&I  Mi  Testing 

The  individual  programs  identified  in  the  PS  shall  be 
coded  in  a  structured  manner  according  to  the  design  of  the 
program  specification.  After  successful  compilation  each 
shall  be  tested  by  a  test  designed  by  the  coder.  After 
successful  testing  the  development  contractor's  quality 
assurance  manager  shall  review  the  programmer's  notebook, 
the  code  and  test  results  to  ensure  that  *he  code  meets  the 
PS  requirements. 

Task  Six  -  System  Integration 

The  individual  programs  will  be  integrated  in+o  a  unit 
and  tested  according  to  the  Program  Test  Plan.  After 
completion  the  software  program  package  and  test  result  will 
be  reviewed  by  the  development  contractors  quality  assurance 
manager.  The  system  operations  and  functions  shall  then  be 


tested  according  to  the  Functional  Test  Plan  and  the  results 


reported  to  FBSO  by  the  development  contractor's  quality 
assurance  manager.  The  Functional  Test  will  be  made  with 
FBSO  representation  present. 

Task  Seven  -  Acceptance  Tasting 

The  software  program  package  shall  fce  installed  at  NSC 
Oakland  and  operated  by  Navy  personnel  for  a  one  month 
period.  The  Navy  shall  log  all  software  incidences  during 
the  period  and  the  development  contractor  shall  correct  any 
deficiences  and  modify  the  system  documentation 
correspondingly.  When  all  deficiences  are  corrected  an 
additional  two  week  test  shall  be  conducted  to  ensure 
correction  of  the  30  day  test  deficiences. 

2a§&  gjgM.  z  User  Manuals 

A  complete  set  of  user  documentation  for  each 
implementation  site  ( 35 1  shall  be  provided  by  the 
contractor.  This  documentation  ill  include  detailed  desk 
procedures  for  purchase  personal  and  an  executive  users 
manual  for  purchase  management  personnel.  This  executive 
manual  will  provide  summary  information  such  as  reports 
available,  options  available,  summary  outline  for  system 
operation,  etc. 

Task  Nine  -  Training 

Training  for  the  user  and  for  the  software  maintaiaer 
shall  be  performed  by  the  development  contractor.  User 
training  shall  be  conducted  for  complete  operation  by 
procurement  buyers  and  clerks.  Additional  material  will  be 
presented  to  guide  the  user  in  obtaining  *he  full  use  of 
hardware  and  software  maintenance  support.  User  training 
shall  be  based  on  the  Osar  Manual  and  shall  consist  of  16 
hours  of  on-site  instruction  at  NSC-Oakland.  Software 
maintenance  training  shall  consist  of  32  hours  of  classroom 
instruction.  Software  maintenance  training  shall  be  based 
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or  the  complete  software  program  package,  all  system 
documentation  (FD,  8D ,  SS,  DS,  PS). 

lz§.k  isfi  _  2aaliti  Assurance  El°2Z12 

The  development  contractor  shall  designate  a  quality 
assurance  manager  who  shall  review  all  documentation  for 
consistency  and  completeness.  He  shall  be  responsible  for 
assuring  that  all  documents  ate  consistent  with  the  final 
product  and  shall  review  all  changasto  the  FD,  HD,  SS,  DS, 
and  PS.  He  will  prepare  the  functional  and  program  test 
plans  and  shall  review  individual  code  tests  prior  to  their 
integration  into  the  system.  He  will  participate  in  the 
system  testing  and  shall  prepare  test  reports  on  the 
results. 
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